up vote 0 down vote favorite
share [g+] share [fb]

I would like to prevent 2 non-root users on the same Linux system from sharing files with each other (via their use of /tmp). Is this possible somehow?

If I restrict /tmp to 0770 (root:root as the owner:group) and define a user-specific TMPDIR via an export TMPDIR=~/tmp; mkdir -p $TMPDIR early on in the boot process (say, via an rc[35].d script), then GConf2 starts having problems. A typical error I then get is:

/usr/libexec/gconf-sanity-check-2 exited with status 256

Everything seems to work fine in Run Level 3 (non GUI)... though I could be wrong in concluding this prematurely, and problems could surface later in Run Level 3 as well.

My experience so far with TMPDIR seems to indicate that it is either broken, or is not sufficiently documented, or is not being embraced by all Gnome applications.

link|improve this question
17% accept rate
feedback

3 Answers

up vote 3 down vote

This would be an extremely bad idea. It violates an extremely widespread (pervasive) and long-standing (as in "from time immemorial") set of assumptions that's likely to be ingrained in a great many applications and utilities.

You'd be far better to create chroot jails or virtual subsystems and confine these users thereby rather than trying to simply lock them out of /tmp.

TMPDIR is only a convention, not a standard. UNIX/Linux programs are free to honor or not at the whims of their authors and maintainers.

link|improve this answer
I read the chroot INFO page, not sure how I would go about making all those 1000s of binaries available under a new root, and that too for each separate user. Would appreciate any further pointers, if you have done this before. Tia, – Harry Jan 3 at 11:10
Unfortunately chroot jails are rather complex and not particularly popular. Additionally they aren't 100% effective as a security measure under certain versions of UNIX/Linux or certain conditions (such as if the same filesystem is mounted under multiple different chroot environments using --bind or similar features). It's even more difficult if your goal is to support and isolated multiple GUI users on the same host. At some point it makes far more sense to create a new VM (virtual machine) for each ... or just give them each their own workstation. – Jim Dennis Jan 3 at 11:40
feedback
up vote 2 down vote

Bad idea as others pointed out. You can use ACLs to get similar result:

groupadd tmpdir-denied
setfacl -m g:tmpdir-denied:- /tmp    # the specific group has no access to /tmp
getfacl /tmp                         # see permissions

Don't get me wrong. The ACL will break things too, if not now then in future, but the impact will be hopefully somewhat limited. I would test as a minimum if I can still (1) backup (2) restore (3) patch system after these changes.

link|improve this answer
Thanks. But can you also tell me how to undo the effect of the above? Basically, I want to be able to get back the original '.' character (denoting default SELinux context) in the output of`ls -ld /tmp`. After issuing your commands, I'm seeing a '+' character, and am not sure how to get it back. – Harry Jan 3 at 14:30
1  
My memory failed, I would need to check it in man. In the meantime let me ask you, is my answer worth an upvote/accept or not? – kubanczyk Jan 3 at 14:45
Yes, surely :-). I was thinking of upvoting a little bit later, as my mind was totally totally preoccupied with the problem. Here you go, my friend... – Harry Jan 3 at 16:21
Great. To remove setfacl -x g:nobody /tmp or to remove all ACLs setfacl -b /tmp. – kubanczyk Jan 3 at 17:18
feedback
up vote 1 down vote

I don't think it is a good idea to change the /tmp permissions. Many applications create files temporary under /tmp and they are not running necessarily under root privileges. So, you will break them if you do so.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.