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

Roger Leigh rleigh at codelibre.net
Tue May 24 09:02:57 PDT 2011


On Mon, May 23, 2011 at 02:42:03PM +0200, Lennart Poettering wrote:
> On Mon, 23.05.11 10:17, 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?  Right now, on Debian, it's not user-writable,
> > > > with the exception of /run/lock (which can be a separate tmpfs mount,
> > > > and we're looking at adding a lock group like other distros use to make
> > > > this not globally writable) and /run/shm (which again is a separate
> > > > tmpfs).
> > > 
> > > Dude, you want to weaken the access restrictions on /run? Uh, no! If we
> > > did that then everybody could just go there are and create /run/dbus and
> > > subsequently D-Bus couldn't be started anymore. 
> > 
> > Having /run/user/$user writable by the user does not imply having /run
> > writable by the user in any case (other than indirectly via DoS using
> > all blocks/inodes).  But in general, I think that having any part of
> > /run user-writable is a legitimate concern--this wasn't part of its
> > original remit, and it /does/ have implications that need careful
> > consideration.
> 
> Well, I certainly always had in mind creating /run/user, when we pushed
> for /run.

Well, it certainly wasn't in *our* minds.

/run as it stands was a relatively uncontroversial change.  It's
just moving /var/run to /run and making it available from the
early initramfs onwards.  /var/run in Debian was already configurable
as a tmpfs, so it was a simple migration and was already entirely
supported by all packages.  The other migrations of /var/lock,
/lib/init/rw and /dev/.* and /dev/shm/* to /run were of data which
already /logically belonged/ under /run but were stored elsewhere, and
were equally uncontroversial--we've had patches to implement /run
since 2003!  (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=186892)

Storing user data under /run *is* controversial, and I object strongly
to it.  It is a big departure from existing practice where the earlier
changes *were not*, and it brings with it a host of issues as mentioned
in other mails.  /tmp exists specifically for this purpose, and while
you've pointed out that problems exist with /tmp, these are entirely
self-inflicted and are easily resolvable.

/run is currently restricted to *system* state, and there are good
reasons for that.  User session state belongs under /tmp; it's no
more special than any other temporary data created by the user.  Note
that cleanup programs such as tmpreaper can be configured to exclude
certain patterns, so it's not like this isn't a simply resolvable
issue--just ensure that session state doesn't get cleaned up and your
problem is fixed.


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/3f3fd71c/attachment.pgp 


More information about the fhs-discuss mailing list