-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/20/2010 07:52 AM, Richard W.M. Jones wrote: > On Tue, Oct 19, 2010 at 04:50:43PM -0400, seth vidal wrote: >> On Tue, 2010-10-19 at 15:40 -0500, Chris Adams wrote: >>> Once upon a time, James Antill <james@xxxxxxxxxxxxxxxxx> said: >>>> Putting my really old sysadmin hat on, one other reason for >>>> having /tmp, /var and /usr as separate mount points was so that you >>>> could allocate different disk space to each (and they couldn't break >>>> each other) ... do we have other solutions for that? >>> >>> On a multi-user server (and that includes web access like PHP or CGI), >>> you really don't want user-writable directories on a filesystem with >>> anything important, especially security-sensitive things like setuid >>> binaries. Hard-link tricks are evil. I run with a separate /tmp >>> (usually tmpfs now) and bind mount it to /var/tmp as well. >> >> Not to get too far off into the weeds but Polyinstantianed tmpdir >> (pam_namespace) are a good idea here. Everyone gets their on /tmp >> and /var/tmp and no one else can see them. > > +1 ... we should have had this a long time ago. > > Rich. > I have been trying to get system processes to stop using /tmp for years. http://danwalsh.livejournal.com/11467.html As some one who lives with polyinstatiated namespace /tmp, The only problem I know of now is handing of kerberos tickets. Whenever a system process (root) needs to communicate with a user via /tmp. namespace /tmp breaks it. sssd can not create kerberos tickets in my /tmp and gssd can not find my kerberos tickets in /tmp. I believe the solution to both is to move the tickets to be managed by sssd and leave /tmp to users. BTW, X has solved this problem a couple of years ago by using virtual namespace for its sockets. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky+3P8ACgkQrlYvE4MpobNZLgCffWqapIi1E1FkfC1TnRjjE/xY 3uoAoIvTwYGvXao91mSzubGiTssKHNAx =Qw58 -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
