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

[Roger Leigh]

On Mon, May 23, 2011 at 02:30:54PM +0200, Lennart Poettering wrote:
> 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.

While having this deficiency fixed would be ideal, we will still need
to cope with older kernels even after it is fixed.

> > > > 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.)

Having some concrete information about what different distributions
do would be useful here.  And I sincerely hope that Debian will not
"fix" this, given the breakage that automated cleaning causes.

> > - /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.

I have read it.  In the context of the FHS, I don't think the text of
the spec means much.  It's fine to say "must", but if a session is
killed unexpectedly it can still fail to clean up despite what the
spec states, and this needs to be considered.

> > 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.

Perhaps.  But in the context of the FHS, how a particular init system
may or may not handle cleanup is not that useful--the FHS needs to be
uniform across all init systems and platforms, and this isn't a
requirement that can be enforced nor guaranteed.

> > 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.

I think the issues you highlight above could be summarised as follows:
"cleanup of /tmp causes massive problems for applications using /tmp".
This really does sound like a "Doctor, it hurts when I do this"
scenario, and the answer is probably "don't do that then".  It's not
at all surprising that removing in-use data causes collateral damage,
and it's really not something that the FHS needs to, or can be
expected to deal with.

Why should applications need to have massively complex code to
workaround cleanup of /tmp, when simply /not/ cleaning /tmp is the
simple solution?

This isn't exactly a new problem.  Aggressive /tmp cleanup on big
Sun/Solaris systems was causing me big problems 15 years ago, and
it's still just as bad today.

Please note that the FHS makes no mention of cleaning /tmp after
startup; it's a site-specific issue left to the admin.  As I said
before: if you choose to enable automated cleanup of /tmp, you do so in
the full knowledge that it will cause breakage.  Expecting that
applications should explicitly cater for such is unrealistic.  While in
theory this could happen to any program at any point in time on a
multiuser, multitasking system as another process makes changes to the
filesystem, most programs would be expected to notice as system calls
fail and bail out appropriately as would be the case for file
operations in any other part of the filesystem hierarchy.  Complex and
fragile workarounds are not a good idea, especially given that cleanup
can introduce "interesting" security issues which are entirely
absent sans cleanup.

> > 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.

As I said above, we need to cater for past and current kernels
irrespective of newer kernels fixing things.  And we could well be
running on non-Linux kernels without tmpfs support as well.  While
the various BSDs chose not to participate in the FHS, Debian does
also run on the FreeBSD and Hurd kernels, and I am taking their
needs into account as well when considering what Debian wants from
the FHS.

As mentioned in other mails: /run /should/ be on a tmpfs, but this
is *not* guaranteed.  It could be just a regular filesystem.  In
consequence, we can not provide the guarantees you desire, even
on plain Linux kernels--consider embedded systems with low memory
and no swap where a tmpfs is too expensive, for example.

> > > I am not sure what session-specific directories would achieve, but
> > > 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).

The FHS shouldn't really be standardising usage based upon current
limitations in the GNOME desktop session and login handling.  And the
same applies to ridiculous limitations in applications like firefox
which refuse to permit multiple instances.  Other desktops and
applications do not have these curious limitations.  You might well
think that it's "pointless" to fix such limitations.  However, the FHS
has a wider scope than this; a "session" might not even necessarily
relate to an "X session".  If set up by PAM, it might be tied to any
other PAM service, including console and SSH logins.  The various
"-agent" processes are usually tied to a single login session, and you
might well want per-session instances (the system I'm writing this
mail on has ssh-agents tied to separate screen sessions).

While the XDG might mandate a certain usage for /run/user for
XDG-compliant applications, the location as standardised in the FHS may
well have users which are FHS compliant yet not XDG compliant.  What
was already concluded as being acceptable to the XDG may not be
acceptable to the FHS--please do bear in mind that it has a rather
wider scope.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
Url : http://lists.linux-foundation.org/pipermail/fhs-discuss/attachments/20110524/aa15f99b/attachment.pgp