F22 System Wide Change: Enable Polyinstantiated /tmp and /var/tmp directories by default

[Huzaifa Sidhpurwala]

On 01/20/2015 05:59 PM, Lennart Poettering wrote:

> 
> Well, /tmp is used by X11 among other for IPC across user 
> boundaries. If you give each other their private instance of it,
> they cannot use this for communication anymore. You are breaking
> X11 this way.
Did you read the attached references to the proposal?
X11 is a special case of needed a shared temp. directory between root
and a no-root process. The reference has a way to solve this problem.

afaik, non-root xorg wont need this hack anymore.

> 
> Moreover, if you want to give each user a private instance of /tmp
> you have to run that user in a private mount namespace and disable 
> propagation from that namespace into the host for the / directory
> for this. (After all the /tmp over-mounting shall be private to the
> user, and not propagate to the rest of the system.)  This of course
> means that if the user later-on invokes /bin/mount or /bin/umount
> on any subdir of / the commands have will have zero effect for the
> rest of the system. You pretty much brek mounting/umounting for
> normal users. If you do this, pretty much every admin will hate you
> deeply.
> 
> Also, introducing "/tmp-inst" sounds really wrong to me, what's
> the point of that? systemd's PrivateTmp= works by mounting /tmp
> over with a subdir of /tmp, so that things stay on the same file
> system. Why introduce a new directory?
> 
/tmp-inst is created with mode 000, as compared to /tmp. As per the
documentation pam_namespace will enforce this mode, unless explicitly
asked to bypass this.

> How do you intend for the new /tmp instance to be life-cycled? When
> is the private /tmp instance removed? On logout? Tracking a user 
> session's lifecycle is not easy, as the user might have processes 
> running that are not attached to any session, and you shouldn't
> remove the private /tmp before those processes are dead too.
> 
Private tmp instances are NOT removed. Only access to them is
restricted to process which run as the $user.

> To me this sounds very much not thought to the end.
> 

Maybe you should try doing this once and see how it scales?

> We thought a couple of times in adding an option for this to 
> systemd/logind, after all, we have the namespacing code in systemd 
> anyway, and we can at least track the sessions through logind very 
> precisely. However, X11 and the mount propagation breakage are
> real blockers to make this useful in the general case.
> 
> This idea can only fly for very special systems where the
> propagation is irrelevant. It's not compatible with admin
> workflows, at all.
> 
> Lennart
> 


-- 
Huzaifa Sidhpurwala / Red Hat Product Security Team