On Wed, 21.01.15 14:34, Huzaifa Sidhpurwala (huzaifas@xxxxxxxxxx) wrote: > 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? I read your feature page. How about adding comments about these things to the proposal itself? > 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. So, are you proposing to run a shell script on each login, that bind mounts the 5 X11 dirs back into each user's tmp directory? That's a hack, little else... > afaik, non-root xorg wont need this hack anymore. Well, the path to the AF_UNIX sockets is compiled into many 3rd party. If you change it, you break things... > > 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. I'd really like to hear your response to this issue. This is a killer really. > > 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. Hmm? I don't follow here... Why is this in anyway better than giving each user his own directory directly below /tmp (with a non-guessable name), that is owned and accessible only to him? > > 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. Well, we have automatic cleanup for /tmp in place for a reason. What's your plan there for /tmp-inst? > > To me this sounds very much not thought to the end. > > Maybe you should try doing this once and see how it scales? I have no doubts about scalability. Also, I implemented all the private /tmp stuff in systemd, for PrivateTmp=. I think I did my homework to be allowed to comment on this. Thanks! I just think that this is not useful in real life on general purpose distros. You can do this on specific machines where you know that it's OK to break mounts from users sessions, and where you know you never will use X11 software. But that's a special case, and inappropriate for a general purpose distro like Fedora. I am also quite sure that the pam_namespace solution which runs privileged shell scripts in the background and duplicates all temp dirs, is hacky, and nothing we should make the default. This feature is really a *bad* idea. Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
