I am a member of the truecrypt group, as my normal user, and can create volumes wherever I have write permissions as such. I've used truecrypt as a normal user for as long as there has been a Linux version of truecrypt. Never have I seen the escalations you describe.
You dont need root's privileges to create volumes that reside in areas you have write access to but you will need root's privileges to open them because a mapper device addresses are created at "/dev/mapper" and you need root's privileges to write to "/dev".
try this, rename your "/etc/sudoers" file and then attempt to open a truecrypt volume, you will be prompted for a password and no password you present will work because truecrypt will attempt to use sudo to elevate its privileges and it will always fail because of a non functional sudo.
If you are a member of truecrypt group and with the sudo setup you have, then trycrypt will run with root's privileges everytime it needs those privileges, it will elevate silently and you can no longer say you are running it as a normal user because you arent.
Dont have a sudoers file and try to open a truecrypt volume from your normal account and tell us what happen. This is the only way you will be 100% sure truecrypt is running with your own privileges and not anybody elses.
I see you still don't grasp the concept of sudo when it's used properly. Your normal user doesn't get privileges elevated arbitrarily through sudo. Each specific command needed to run truecrypt as a normal user, transparently, is set up in sudo, and only those commands are run with root privileges, not by the user directly, but through truecrypt; in this case the ability to mount and unmount truecrypt volumes, and only those for which the volume passwords are known.. This is not blanket root privileges that can be escalated.
Mount and umount are activities
reserved to
root. When you use Dolphin to mount a partition as a normal user, it ends up in
/media/<something>, without needing a root password, because hal-mount (or dev-mount) does something similar, treating it as if it were a removable device. Are you worried about privilege escalation here?
When you set up fstab to allow user mounting of optical devices, floppy disks, zip drives, or data partitions, root is needed initially, to do this. Root can simply say, "
I give this right, to mount and unmount, to normal users for these specific volumes." Once set up, normal users can mount and unmount the specified volumes, without having to su to root or entering a root password. Are you worried about privilege escalation from fstab?
Sudo, in this case, uses the same principal; root transfers the specific right, to a normal user in the truecrypt group, for the mounting of truecrypt volumes, through truecrypt, which are items not to be found in fstab. There is no more danger of privilege escalation than there is from a properly set up fstab.
I also have, in my
/etc/sudoers file, this line;
polack ALL=(ALL) NOPASSWD:/bin/mount,/bin/umountI don't use that to enter
sudo mount <something> <somewhere> in terminals, in a willy-nilly manner. It's necessary to run these two aliases;
alias imnt='mkdir ~/Desktop/iso && sudo mount -o loop *.[i-I][s-S][o-O] ~/Desktop/iso && konqueror ~/Desktop/iso && cl'
alias umnt='sudo umount ~/Desktop/iso && rmdir ~/Desktop/iso'
With four letters,
imnt, I can loop mount any .iso image on a newly created, specific mountpoint directory, and view its contents in the konqueror file manager that is then opened. I use this a lot for setting up
liveHDD versions of all the various PCLinuxOS releases. The alias only works from within the actual directory holding the single .iso image.
When done, another four letters,
umnt, unmounts the image and deletes the mountpoint directory from my desktop. This alias can be used from any terminal, at any location, but usually the one from which the first was entered.
