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

Roger Leigh rleigh at codelibre.net
Mon May 23 02:17:48 PDT 2011


On Mon, May 23, 2011 at 12:26:06AM +0200, Lennart Poettering wrote:
> On Sun, 22.05.11 21:35, Roger Leigh (rleigh at codelibre.net) wrote:
> 
> > On Sun, May 22, 2011 at 09:51:12PM +0200, Lennart Poettering wrote:
> > > On Sun, 22.05.11 19:23, Richard Hartmann (richih.mailinglist at gmail.com) wrote:
> > > 
> > > > 
> > > > On Sun, May 22, 2011 at 18:29, Lennart Poettering
> > > > <lennart at poettering.net> wrote:
> > > > 
> > > > > Look for XDG_RUNTIME_DIR.
> > > > 
> > > > Purrrrrfect.
> > > > 
> > > > 
> > > > What do you think about putting that into /run, then? Assuming /run
> > > > exists, that is.
> > > 
> > > Yes, that's where it is located by default.
> > > 
> > > $ echo $XDG_RUNTIME_DIR 
> > > /run/user/lennart
> > 
> > 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.

> > 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 is a shared namespace. That means you have to store your stuff
> under randomized names in it, which makes it very much unsuitable for
> the purposed of $XDG_RUNTIME_DIR, which is to be a place for sockets and
> similar communication primitives (like pid files, ...)

But XDG_RUNTIME_DIR is an environment variable.  What's the problem with
creating a directory under /tmp with a randomised name, then setting the
env var?  pam_tmpdir already has this functionality, and all this can be
set up at login by PAM.  I fail to see why /tmp is unsuitable for this
purpose, and why we must use /run.  IMO it seems like an abuse of /run
to use it for user data.

Regarding the lifetime of files under /tmp and /run: cleaning of files
under /tmp is entirely up to local policy set by the sysadmin.  Mine
is never cleaned.  At least on Debian, you have to take deliberate
action to set this with e.g. tmpreaper, and you do so in the knowledge
that it can (and will) cause problems.  This is not something we should
need to work around in standards or applications--it's not done by
default, and it brings with it all sorts of hairy problems like how
frequently to touch the files to update the mtimes (we can't guess the
admin's policy here).  By default the lifetime of files on both /run
and /tmp are the same: present until shutdown/reboot.


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/20110523/d9cd156d/attachment-0001.pgp 


More information about the fhs-discuss mailing list