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

Lennart Poettering lennart at poettering.net
Tue May 24 10:29:26 PDT 2011


On Tue, 24.05.11 16:36, Roger Leigh (rleigh at codelibre.net) wrote:

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

UH? Why? There's really no point in running old kernels on new
distributions. The other way round might make more sense...

And you cannot fix the /dev/shm problem anyway, so why do you bother? I
know Debian tries to fix all problems with shell scripts, but seriously:
fix in the kernel what should be fixed in the kernel.

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

Fedora (and by extension RHEL) has been shipping with this since about
always, and I am not aware of any open bugs. If Fedora can do it, then
Debian should be able to, as well. 

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

No. In systemd (git) this cannot happen.

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

Oh, hell, it can be enforced, just write your software properly. You
shouldn't build into the spec provisions for "I want to use broken
software". If you really hate systemd so much, then reimplement that
feature, but don't weaken the specification for that.

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

No, you misunderstood this completely.

The problem is the shared namespace and the fact that things might end
up lurking around forever.

The age-based clean up is a fix for the latter problem, not the caise
for the problem.

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

I think you are confused.

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

Uh?

Aren't you the one who thinks the issue that /run/user or /dev/shm might
run full needs immediate hackish fixing? And now you are arguing the
contrary, that /tmp running full should be a good thing?

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

Hmm, maybe it was a problem 15y ago on Solaris. It isn't on today's
Fedora...

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

I think you are seeing problems where there aren't any problems, and not
seeing the actual problems that exist.

Note that all systemd-based systems clean up /tmp by default. This is
the only sane thing to do.

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

Oh god. I really hope that legacy support for toy OSes nobody uses and
legacy kernels won't pollute the FHS. What you are doing is not bringing
Linux forward, but holding it back.

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

On systemd /run is guaranteed to be tmpfs. I think the tmpfs being too
expensive claim is a myth you are simply using to retroactively justify
Debian's non-sensical configurability choices. Such a problem does not
really exist.

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

Oh my, I see. XDG = bad, FHS = good. 

Jeez, man. 

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the fhs-discuss mailing list