Help with running a Truecrypt volume as user, not root please
 

Hi all,

I have a post about this on the Truecrypt forum but thought maybe I should try here and on the suse forum since no one has responded there yet and frankly, I have a feeling that my problem may be something in the system, not truecrypt.

I have an encrypted folder I created under Truecrypt Windows. In order to mount it here, I use:

# truecrypt -u /dev/sdb1 /home/eric/Desktop/tc

This mounts the volume just fine. Trouble is, it mounts it only as root, which means as a regular user I have no access to read/write priveleges. I've tried running truecrypt without going into su mode but it keeps insisting I need root priveleges. I'm not sure if that's because I'm mounting a drive or because truecrypt wants me to be in root for that. I do know the -u argument is supposed to set the volume to ownership of the default user, which should be "eric." Not root. But it keeps setting it as root anyway. Is there any way to figure out under OpenSuse 10.2 who the default user is? My only guess is that the problem is that somehow root is listed as default user. Either that, or I'm doing something else wrong.

Oh, also, the encrypted volume is in fat32 format. So I don't have the NTFS writing problem. But I do know that the owner needs to be set for that volume otherwise it is impossible to set permissions for it. I'd rather not switch it to ext3 since from what I understand, that could cause problems with encrypted volumes (due to things being spread all around and the chance that the metadata may be corrupted), plus, I don't like the whole idea of metadata being available for something encrypted. . .

I tried opening Yast and looking at user settings, but could find nothing to help me there. . .

Thanks in advance.

Eric

Post the output of:

$ ls -l /usr/bin/truecrypt

It may just be a permission problem. On my system, truecrypt has SUID set with root ownership:

If you don't have SUID set on yours, you can try resetting the permissions with:

# chmod 4755 /usr/bin/truecrypt

and see if it works.

This is what I get for the first command:

-rwxr-xr-x 1 root root 247564 2006-12-21 12:25 /usr/bin/truecrypt

I tried the chmod and it seems to be working perfectly. Thank you so much. I'm not 100% certain what I did just now, but I'm absolutely thrilled it's working.

Eric

I guess I should explain a bit. SUID is short for "Set UID". Just as every file in linux has an owner, this concept of ownership also applies to programs in execution(processes) as well. Even though truecrypt is owned by root all users have execute permission on the file. This is typical of many command line utilities like tar, cp, mv, etc.

The general rule is that whoever launches a process will have ownership of a process and the process will have the same limits on it that the user that launched it has regardless of who actually owns the executable(typically root). This generally works out fine; programs are available to users but they don't have the ability to change the program file or do some damage that only root can do. However, certain executables, like truecrypt, invoke other processes that only root can start. That's why you get a permission denied problem when you launch truecrypt as an ordinary user.

SUID is a way to get around this problem. When an executable is given SUID permissions, whenever the executable is launched the resulting process will have the ownership of the owner of the executable, not the person launching the process. Thus, if the executable is owned by root, no matter who launches it, the resulting process will have root ownership and root powers. This can be a security concern so you generally want to limit SUID programs to an absolute minimum.

A more secure alternative is to use "sudo" which, when properly configured, allows you to give only certain designated users the ability to launch a program SUID. It's probably overkill for a home user, but you might want to look into how sudo works for your own edification. That's certainly the way you would handle these types of problems in a multiuser commercial environment.

Thanks again for the info and the explanation. Truly extremely helpful. It is greatly appreciated.

Eric