On Mar 18, 2014 12:59 PM, "Leonid Isaev" <<a href="mailto:lisaev@umail.iu.edu">lisaev@umail.iu.edu</a>> wrote: > > [Sorry, forgot to CC the mailing list] > > Hi Lennart, > > On Tue, 18 Mar 2014 02:33:50 +0100 > Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote: > > > On Mon, 17.03.14 19:04, Leonid Isaev (<a href="mailto:lisaev@umail.iu.edu">lisaev@umail.iu.edu</a>) wrote: > > > > > Hi, > > > > > > Currently, XDG_RUNTIME_DIR=/run/user/<UID> is mounted with rather > > > permissive, hardcoded mount options (or at least I couldn't find a > > > documented way of changing them). Specifically, a user is allowed to > > > execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's > > > ability to constrain users, e.g. by mounting /home as noexec (I have seen > > > this done in some environments). > > > Is there a need to allow execution from $XDG_RUNTIME_DIR? And how > > > should one configure its mount options? > > > > Yes, this is hardcoded in 211, that's true. We could make this > > configurable but I am not really convinced that we really want that? > > I agree that a complete, fstab-like configuration may be too much. > > > > > I mean, the XDG_RUNTIME_DIR spec says the dir "must be fully-featured by > > the standards of the operating system. More specifically, ... proper > > permissions ... must be supported". I'd read that as if the x bit should > > do what it is supposed to do. So, in order to stay compatible with the > > spec allowing to mount it with noexec sounds undesirable. > > Well, regardless of what the XDG specification says, the fact is that currently > each user has 2 /home's: one under the admin control, another -- not. > > Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR > upon login, but this is hacking around the init system... What about making > XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate > partition and fall back to the current default otherwise? > > > > > Moreover "noexec" is mostly snake-oil, isn't it? You can invoke the > > executables with an interpreter still, and you can copy the files > > elsewhere... > > True for the interpreted code. And compiled code. The linker is your ELF interpreter. > However regarding other places, if an admin > cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also > constrained (I am not saying that this should be the default, just > configurable). > > Thanks, > Leonid. > > > > > Note that setting "noexec" on an fs means you cannot maps its files > > PROT_EXEC anymore, which breaks a number of things. In the past people > > attempted to mount /dev/shm as noexec, and dosemu broke because it made > > use of this. Then people wanted to mount /dev as noexec, which broke X11 > > which wanted to map some device nodes PROT_EXEC. Given that we consider > > XDG_RUNTIME_DIR as a private version of /dev/shm among other things it > > really sounds wrong to break this right from the start. > > > > > So, I am not really convinced I must say... > > > > Lennart > > > > > > -- > Leonid Isaev > GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D > > _______________________________________________ > systemd-devel mailing list > <a href="mailto:systemd-devel@lists.freedesktop.org">systemd-devel@lists.freedesktop.org</a> > <a href="http://lists.freedesktop.org/mailman/listinfo/systemd-devel">http://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> >