[systemd-devel] Mount options for $XDG_RUNTIME_DIR

[Lennart Poettering]

On Tue, 18.03.14 12:59, Leonid Isaev (lisaev at 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