Proposing Fedora Feature for private /tmp and /var/tmp for all systemd services in Fedora 17.

[Lennart Poettering]

On Tue, 08.11.11 09:07, Daniel J Walsh (dwalsh at redhat.com) wrote:

> > Yes, this works as it always did. We made sure that the behaviour
> > change is as minimal as possible and all the accounting and
> > discoverability is unchanged.
> > 
> > Lennart
> 
> One suggestion would be to create a directory in /tmp at early boot.
> /tmp/.systemd  Which would only have root only access.
> 
> ls -ld /tmp/.systemd/
> drwx------. 2 root root 40 Nov  8 09:04 /tmp/.systemd/
> 
> When systemd boots before it starts any other processes it could check
> for the existance of this directory and if it has any permissions that
> differ, destroy it and recreate it.  Then it could create the services
> directories underneath it with well known names.  And bind mount those
> directories over /tmp.  Then it would be easier for the administrators
> to find the /tmp directories.

We do something similar for the X11 socket dirs, which have well-known
names. We pre-create them at boot to avoid the vulnerabilities that evil
local users might create their own subdirs in their place.

That said, I am not particularly keen on having an inflation of subdirs
in /tmp created at early boot. I'd much prefer if we design our stuff in
a robust way so that directories are created when they are needed, but
without them being guessable.

But yeah, pre-creating those dirs definitely would fix the issue, but
maybe all of this is just thinking about problems that don't exist,
since so far nobody complained too loudly about the the
non-recognizability of the private tmp dirs below /tmp. (Which obviously
is because nobody is using this yet, but well...) 

So I think the current solution (fully random subdirs in /tmp) is good
enough to get things going. If there's enough reason and pressure to
make the randomized subdirs recognizable then we definitely can do
something about it, but it's probably not worth thinking too much about
that before that.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.