rawhide report: 20101019 changes

Daniel J Walsh dwalsh at redhat.com
Wed Oct 20 12:13:51 UTC 2010


-----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 at fedoraproject.org> 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-----


More information about the devel mailing list