On Tue, 18.03.14 12:59, Leonid Isaev (lis...@umail.iu.edu) wrote: > > 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.
Well, the XDG runtime dir is not really a home directory. It has very clear semantics and lifecycles, and they are quite different from /home. > 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? So when we standardized XDG_RUNTIME_DIR we did so because of the broken semantics of /home, where there's no guarantee that file locking, mmapping, unix sockets, fifos, exec, ... would work correctly. Hence for local runtime stuff we came up with XDG_RUNTIME_DIR, which should clean all this up, have a clear lifecycle and be the much better place for doing all these things. It sounds really backwards to me to weaken this clear definition by making some of the features completely optional again. I mean, it's fine if people locally override how things are set up, and willingly break what is written in the spec, but I am pretty sure we shouldn't push them to do that by making this too easy to change. Or with other words: what you want to do there is explicitly what you say you don't want to do: hacking around the init system! So, if you want to do that, then go ahead, but I really doubt we should support anything like this with an easy option upstream. Sorry. > > 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. 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). Well, the ELF interpretor stuff means noexec is pretty much entirely useless. I only see drawbacks of this I must say. I really don't see the benefit of adding a config option for this. Sorry, Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
