[fhs-discuss] user-specific directories in /run

[Lennart Poettering]

On Mon, 23.05.11 10:35, Roger Leigh (rleigh at codelibre.net) wrote:

> On Mon, May 23, 2011 at 01:10:32AM +0200, Richard Hartmann wrote:
> > On Sun, May 22, 2011 at 22:35, Roger Leigh <rleigh at codelibre.net> wrote:
> > 
> > > Do we want to allow users to create files under /run, or reserve it
> > > solely for system use?
> > 
> > No, that is why I wanted user-specific directories.
> 
> From the POV of the system being guaranteed to be able to create
> files in /run e.g. when starting a service, or to be able to continue
> to append to datafiles (samba), you do not want the user to be able
> to fill up that filesystem.  It's especially important here because
> there's no 5% "reserved" blocks like on ext, so any user could, either
> accidentally or deliberately, break the entire system.  I really don't
> want that, and this does need to be considered lest our systems
> become vulerable to simple local DoS.

This is a general problem by which /dev/shm, /tmp and /run/user
suffer. It's on the todo list to fix this in the kernel by providing
something quota-like (for example an rlimit) on tmpfs.

> > > What makes /tmp unsuitable for this purpose?  It's already possible
> > > to securely create directories owned by the user there, and these
> > > runtime files are, by definition, temporary.
> > 
> > /tmp will most likely be cleared out from time to time. /run is guaranteed to.
> 
> I don't agree with either of these assertions.
> 
> - /tmp isn't cleaned by default.

It is on most distributions I think (maybe not Debian though, but they
should fix that.)

> - /run/user won't be cleaned by default either.

Please read the XDG_RUNTIME_DIR spec. Its a *MUST* that this directory
is removed after a complete logout.

> However, consider that on a busy or long running system that you'll
> end up with stray session directories under /run/user as well. 

That would be a weakness in your implementation. On a systemd system
this doesn't happen.

> At that point you'll be in the same situation as /tmp, and you'll
> need to clean them *both*...  In consequence, I don't think that /run
> is a better choice than /tmp.

I think PulsedAudio is the only application that ever got it right
placing a socket in /tmp. And the code for that is massive. I am not
sure you understand the complexity of this. i.e. You need to create a
random directory in /tmp, and then add a symlink in $HOME to that dir,
so that you can access it under a well-defined name. The complexity now
is added on top of that in that this symlink needs to include a machine
id of some kind to not break NFS, and you need to ensure that the
directory in /tmp is really yours in case /tmp was cleaned up since you
created the dir in it. That is just crazy. In fact the entirety of /tmp
is just a gigantic fuckup.

The advantages of /run/user/$USER is the guaranteed cleanup and private
namespace, which makes it very easy to write safe code that doesn't
pollute the file systemd over long.

> If we do go this route, I'll have to make /run/user an additional
> tmpfs mount for Debian to make it safe.

No, you shouldn't. Just wait until the kernel is fixed, or even better:
fix it yourself.

Don't try to tape over problems in userspace that should fixed in
kernelspace.

> > I am not sure what session-specific directories would achieve, but
> > 
> >   /run/user/$USER/session.d/XXXXXXXXXX
> > or
> >   /run/user/$USER/sessions/XXXXXXXXXX
> > or
> >   /run/user/$USER/session/XXXXXXXXXX
> > 
> > could be created easily.
> > 
> >   $XDG_RUNTIME_SESSION_DIR
> > 
> > could hold the link to it. I am still not sure what its use would be, though.
> 
> Its purpose would be to keep each session separate.  We don't limit
> users to one login session, so why would we want to share the session
> state between multiple sessions?  If sharing, it also brings with it
> the problem of who cleans up the session directory, and when; if they
> are separate, it's clear who has that responsibility (the initiating
> process), and when it should be done (end of session).

If services are per-session then they should simply include a session
identifier in the files/sockets they create in /run/user.

I think putting an emphasis on multiple sessions per user is wrong
though. Most terminal user services are per-user (not per-session)
anyway (i.e. gpg-agent, ssh-agent, ...). And desktops like GNOME (or the
popular apps, like firefox, ...) cannot really cope with multiple
simultaneous graphical logins anyway. And fixing that is kinda
pointless. (Yeah, I am sure you disagree with that and believe that
multiple X11 sessions is something we totally should support, but
everybody who worked on the XDG stuff was convinced otherwise, and I am
not going to reopen that discussion again).

Lennart

-- 
Lennart Poettering - Red Hat, Inc.