Just a thought:
/etc/profile.d/tmpdir.sh:
# For privacy and security, set temporary directories to ~/tmp on local # filesystems -- but for network filesystems, make up one in /tmp. # The trap statement cleans up the temporary directory if it's empty on exit.
if [ -z "$TMP" ]; then if [ $EUID -ne 0 ] && [ -d $HOME/tmp ] && [ $( df --local $HOME | wc -l ) -gt 1 ]; then TMP=$HOME/tmp else TMP=$( mktemp -d /tmp/${HOSTNAME}.tmp.XXXXXXXX ) || exit 1 trap "rmdir --ignore-fail-on-non-empty $TMP" EXIT fi fi
if [ -z "$TMPDIR" ]; then TMPDIR=$TMP fi
On Thu, 2005-05-12 at 11:55 -0400, Matthew Miller wrote:
Just a thought:
/etc/profile.d/tmpdir.sh:
# For privacy and security, set temporary directories to ~/tmp on local # filesystems -- but for network filesystems, make up one in /tmp. # The trap statement cleans up the temporary directory if it's empty on exit.
Why not use /tmp/<username> instead?
On Thu, May 12, 2005 at 11:59:28AM -0400, Ignacio Vazquez-Abrams wrote:
# For privacy and security, set temporary directories to ~/tmp on local # filesystems -- but for network filesystems, make up one in /tmp. # The trap statement cleans up the temporary directory if it's empty on
Why not use /tmp/<username> instead?
Because avoiding using predictable filenames is one of the advantages.
On Thu, 2005-05-12 at 11:55 -0400, Matthew Miller wrote:
Just a thought:
/etc/profile.d/tmpdir.sh:
# For privacy and security, set temporary directories to ~/tmp on local
There's actually been some work going on on giving each user their own /tmp namespace via the kernel's CLONE_NEWNS capability and a PAM module, AIUI. To the system administrator this could appear as /tmp/<username>. I think the problem is in getting later mounts to actually appear in the cloned namespace.
On Thu, May 12, 2005 at 12:03:28PM -0400, Colin Walters wrote:
# For privacy and security, set temporary directories to ~/tmp on local
There's actually been some work going on on giving each user their own /tmp namespace via the kernel's CLONE_NEWNS capability and a PAM module, AIUI. To the system administrator this could appear as /tmp/<username>. I think the problem is in getting later mounts to actually appear in the cloned namespace.
Ooh, that's kinda cool. This is easier, though. :)
Colin Walters wrote:
On Thu, 2005-05-12 at 11:55 -0400, Matthew Miller wrote:
Just a thought:
/etc/profile.d/tmpdir.sh:
# For privacy and security, set temporary directories to ~/tmp on local
There's actually been some work going on on giving each user their own /tmp namespace via the kernel's CLONE_NEWNS capability and a PAM module, AIUI. To the system administrator this could appear as /tmp/<username>. I think the problem is in getting later mounts to actually appear in the cloned namespace.
We probably should be putting out such information on a roadmap page for Fedora instead of waiting for related topics to pop out. If we cant get a general roadmap out, we can probably look at short term goals for every Fedora version in a wiki. will this work out?
regards Rahul
walters@redhat.com (Colin Walters) writes:
There's actually been some work going on on giving each user their own /tmp namespace via the kernel's CLONE_NEWNS capability and a PAM module, AIUI. To the system administrator this could appear as /tmp/<username>. I think the problem is in getting later mounts to actually appear in the cloned namespace.
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
* there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
* namespaces are causing problems with automounters
* 'mount --bind' does not accept/honor options like 'noatime' or 'noexec' (which could be usefully e.g. to mount $HOME/tmp as /tmp). Patches are existing but responsible kernel maintainer refuses to apply them :(
* CLONE_NEWNS + 'mount --bind' are not very well documented and it is often unclear whether strange behavior is expected or not. E.g. it may happen that '/' and '/..' are pointing to different inodes; dunno if this is wanted or not.
Enrico
On Wed, 2005-05-18 at 20:15 +0200, Enrico Scholz wrote:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
- namespaces are causing problems with automounters
Sounds like a regular bug; I don't think automounters would come into play for /tmp anyways?
- 'mount --bind' does not accept/honor options like 'noatime' or 'noexec' (which could be usefully e.g. to mount $HOME/tmp as /tmp). Patches are existing but responsible kernel maintainer refuses to apply them :(
noexec's always been virtually useless. noatime is useful, but not so much that it would be a showstopper for CLONE_NEWNS, in my opinion.
- CLONE_NEWNS + 'mount --bind' are not very well documented and it is often unclear whether strange behavior is expected or not. E.g. it may happen that '/' and '/..' are pointing to different inodes; dunno if this is wanted or not.
Hm, so it might confuse tools? I'd imagine most tools out there recurse downwards into a path and so won't hit that issue, but it is something to watch out for.
Colin Walters (walters@redhat.com) said:
On Wed, 2005-05-18 at 20:15 +0200, Enrico Scholz wrote:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
Well, there's agent sockets and the like in your tmp dir.
Bill
On Wed, 2005-05-18 at 18:48 -0400, Bill Nottingham wrote:
Colin Walters (walters@redhat.com) said:
On Wed, 2005-05-18 at 20:15 +0200, Enrico Scholz wrote:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
Well, there's agent sockets and the like in your tmp dir.
Yes, but if all namespaces bind mount the same tmp dir, it doesn't matter that processes are running in different namespaces.
On Wed, 2005-05-18 at 18:48 -0400, Bill Nottingham wrote:
Colin Walters (walters@redhat.com) said:
On Wed, 2005-05-18 at 20:15 +0200, Enrico Scholz wrote:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
Well, there's agent sockets and the like in your tmp dir.
Not sure if this is related but....
With regard to tmp directories, I'd like to see two things as default:
1. Each user should have there own ~/tmp space which only they can access. This could be used for the users agent sockets, but also just for general files that they would put in /tmp. This would give a better level of privacy (for whatever reason, but maybe simply so they don't have to think about the privacy implications of putting things in a publically accessible /tmp folder)
2. The system should have a general 'shared' folder that appears as a folder in each users home directory, but where any files placed there can be accessed by anyone else. This folder shouldn't delete files after a period like /tmp does, and if shouldn't cause problems with ownership (a security issue maybe). My father, who worked at the Bureau of Meteorology in Melbourne and who has use Unix as part of that always comments that one of the biggest issues he had was being able to simply share files with others without having to contact a sysadmin just to get a 'shared folder' set up. My wife concurs with him, thinking it's mad that she has to put important files in /tmp just to be able to share them, and while I could do something about this, the reality is that they would both like it to be done without having to ask anyone. (It's a small sample size, but I'm sure others have heard similar comments. 8-] )
Thoughts (and beratings ;-] )
R.
On Thu, 2005-05-19 at 10:32 +1000, Rodd Clarkson wrote:
- Each user should have there own ~/tmp space which only they can
access. This could be used for the users agent sockets, but also just for general files that they would put in /tmp. This would give a better level of privacy (for whatever reason, but maybe simply so they don't have to think about the privacy implications of putting things in a publically accessible /tmp folder)
Of course, ~/tmp/ really sucks for this -- lots of places use nfs homedirs, and you'd rather not put the sort of stuff you use /tmp for on the network.
On Tue, May 24, 2005 at 06:18:43PM -0400, Peter Jones wrote:
- Each user should have there own ~/tmp space which only they can
access. This could be used for the users agent sockets, but also just
[...]
Of course, ~/tmp/ really sucks for this -- lots of places use nfs homedirs, and you'd rather not put the sort of stuff you use /tmp for on the network.
Which goes back to my original post here, which cleverly (?) checks if ~/tmp is on a local filesystem and uses mktemp in /tmp otherwise.
(PS: there's an obvious error in that first post, in that the variables should be actually exported.)
On Tue, 2005-05-24 at 18:24 -0400, Matthew Miller wrote:
On Tue, May 24, 2005 at 06:18:43PM -0400, Peter Jones wrote:
- Each user should have there own ~/tmp space which only they can
access. This could be used for the users agent sockets, but also just
[...]
Of course, ~/tmp/ really sucks for this -- lots of places use nfs homedirs, and you'd rather not put the sort of stuff you use /tmp for on the network.
Which goes back to my original post here, which cleverly (?) checks if ~/tmp is on a local filesystem and uses mktemp in /tmp otherwise.
Yeah, that's better than just blindly using ~/tmp/. But why have the extra complexity? Why not always do mktemp and the bind+namespace magic? This does have some advantage -- all users' tmp dirs are created the way the admin intended when he set the system up, and they're easy to find if he needs to look for them, for whatever reason.
On Fri, May 27, 2005 at 04:15:45PM -0400, Peter Jones wrote:
Yeah, that's better than just blindly using ~/tmp/. But why have the extra complexity? Why not always do mktemp and the bind+namespace magic? This does have some advantage -- all users' tmp dirs are created the way the admin intended when he set the system up, and they're easy to find if he needs to look for them, for whatever reason.
There is another ~/tmp problem to worry about. Quite a few programs behave badly on start up if they can't write to their tmp files. ~/tmp combined with quota will make this worse.
Alan (who used /tmp/$USER as /tmp when playing with this stuff)
On Fri, May 27, 2005 at 04:15:45PM -0400, Peter Jones wrote:
Yeah, that's better than just blindly using ~/tmp/. But why have the extra complexity? Why not always do mktemp and the bind+namespace magic? This does have some advantage -- all users' tmp dirs are created the way the admin intended when he set the system up, and they're easy to find if he needs to look for them, for whatever reason.
Well, at this point, the bind+namespace magic is more complex. But it seems sufficiently promising that it's probably worth waiting until it's solid before implementing anything.
On Wed, 2005-05-18 at 18:48 -0400, Bill Nottingham wrote:
Colin Walters (walters@redhat.com) said:
On Wed, 2005-05-18 at 20:15 +0200, Enrico Scholz wrote:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
Well, there's agent sockets and the like in your tmp dir.
Sure. But you weren't expecting to share an agent between separate ssh logins, were you? Defining a per-machine "session" gets terribly hackish, as the Gentoo keychain program shows. You get into this whole mess of trying to get some way of communicating data between independent logins, which gets a lot more difficult than "stuff it in ~/.foo" with fun things like NFS /home in the mix. /tmp is problematic since you can't use well-known filenames. You basically end up having to trawl /tmp looking for an active socket or something, or try ~/.foo/$hostname/bar, and $hostname has its own problems...
On May 18, 2005, Colin Walters walters@redhat.com wrote:
Sure. But you weren't expecting to share an agent between separate ssh logins, were you?
That would be quite useful. I often leave GNU screen sessions behind, whose SSH agent sockets are removed when I disconnect, and then, when I reconnect, all I have to do to be able to ssh into other boxes again is to set SSH_AUTH_SOCK to the newly-created agent. With separate namespaces, there's just no way to get to that agent from the running screen session.
walters@redhat.com (Colin Walters) writes:
This CLONE_NEWNS and (related) 'mount --bind' operations are not very well supported by the kernel:
- there does not exist a way to enter an already existing namespace; so, e.g. two different ssh sessions would have different /tmp directories
Right, but that shouldn't be a problem since you can share data via your home directory or a specially-designated scratch area, etc.
It will cause lot of problems when two regular sessions have a different view of the filesystem. E.g. when session A mounts /media/cdrom, this will not be available in session B. When B mounts it also, the unmounting will become funny as the kernel but not processes (detectable with 'fuser -m') locks this device.
Or, when administrator mounts additional devices in the root-NS, this will not be reflected in the NS.
Or the /etc/mtab designflaw of 'mount'... it is not NS aware, and although it causes other problems e.g. in read-only / it was impossible to eradicate it in all the years.
- namespaces are causing problems with automounters
Sounds like a regular bug; I don't think automounters would come into play for /tmp anyways?
Think of automounting /home/foo: In root-namespace (where the automounter was started), nobody accessed this dir and is is not mounted yet.
Now, 'foo' opens a session A which creates a new namespace and tries to access his homedir. automounter sees that and mounts it; either in the root-NS (which keeps /home/foo still inaccessible for session A) or in the NS of session A. In fact, current automounters will do only the first option, are NS unaware and will be confused by them.
All this is more than I could write in a bugreport; design flaws of current automounters are well known and documented e.g. in
ftp://ftp-eng.cobalt.com/pub/whitepapers/autofs/towards_a_modern_autofs.txt
- 'mount --bind' does not accept/honor options like 'noatime' or 'noexec' (which could be usefully e.g. to mount $HOME/tmp as /tmp). Patches are existing but responsible kernel maintainer refuses to apply them :(
noexec's always been virtually useless.
Why? The '/lib/ld-2... /tmp/foo' trick does not work anymore with recent kernels.
- CLONE_NEWNS + 'mount --bind' are not very well documented and it is often unclear whether strange behavior is expected or not. E.g. it may happen that '/' and '/..' are pointing to different inodes; dunno if this is wanted or not.
Hm, so it might confuse tools?
Yes, it breaks e.g. chroot operations of yum.
Enrico
On Thu, 2005-05-19 at 08:04 +0200, Enrico Scholz wrote:
It will cause lot of problems when two regular sessions have a different view of the filesystem. E.g. when session A mounts /media/cdrom, this will not be available in session B.
Work is going on on making "shared subtrees" as I think they're called working upstream.
Or the /etc/mtab designflaw of 'mount'... it is not NS aware, and although it causes other problems e.g. in read-only / it was impossible to eradicate it in all the years.
Yeah...that's a can of worms.
Think of automounting /home/foo: In root-namespace (where the automounter was started), nobody accessed this dir and is is not mounted yet.
I think this is essentially the same issue as the first one; if we have shared subtrees then this should work.
noexec's always been virtually useless.
Why? The '/lib/ld-2... /tmp/foo' trick does not work anymore with recent kernels.
That's cool that that hole is closed, although I wonder if there are other ones. Besides that, there's a few other facets of "useless": first, that lots of things break on noexec /tmp, and second, you need to ensure that there aren't any other writable areas that aren't mounted noexec, and third, SELinux gives you a much more fine-grained control over execute permissions anyways.
- CLONE_NEWNS + 'mount --bind' are not very well documented and it is often unclear whether strange behavior is expected or not. E.g. it may happen that '/' and '/..' are pointing to different inodes; dunno if this is wanted or not.
Hm, so it might confuse tools?
Yes, it breaks e.g. chroot operations of yum.
Even just for a new /tmp namespace? Seems surprising.
mattdm@mattdm.org (Matthew Miller) writes:
Just a thought:
/etc/profile.d/tmpdir.sh:
FWIW... I use
| #! /bin/bash | | T=/var/tmp/sessiondir-$USER | | dir= | for i in $T.*; do | test -d "$i" -a -O "$i" -a ! -L "$i" -a "$i" -nt /.autofsck || continue | dir="$i" | done | | test -n "$dir" || { | dir=$(mktemp -d "$T.$(date +%s).XXXXXX") && \ | mkdir -p $dir/{tmp,redhat/{SOURCES,RPMS/{i{3,4,5,6}86,noarch,x86_64},SPECS,SRPMS,BUILD}} \ | $dir/cvsextras && \ | ln -s ../SRPMS $dir/redhat/RPMS/ | } || { | echo "Failed to create tempdir" >&2 | exit 1 | } | | tmp="export ENSC_SESSIONDIR=$dir" | eval $tmp | echo "$tmp"
to create a session directory. It assigns one temporary directory per machine cycle (detected by age of /.autofsck). So, e.g. two parallel ssh logins will have the same sessiondir. Adding the date to its name make 'ls -l ...' show the recent directory last.
Enrico