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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
