[fhs-discuss] user-specific directories in /run
Lennart Poettering
lennart at poettering.net
Mon May 23 05:30:54 PDT 2011
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.
More information about the fhs-discuss
mailing list