On Mon, May 23, 2011 at 01:10:32AM +0200, Richard Hartmann wrote:
> On Sun, May 22, 2011 at 22:35, Roger Leigh <[email protected]> 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.

> > 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.
- /run/user won't be cleaned by default either.

However, consider that on a busy or long running system that you'll
end up with stray session directories under /run/user as well.  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.

If we do go this route, I'll have to make /run/user an additional
tmpfs mount for Debian to make it safe.

> > The above scheme also looks like it only creates a single
> > directory per user; one may have multiple sessions, so I fail to see
> > how a temporary directory under /tmp or /tmp/user would be any worse
> > than /run.  Either may be a tmpfs; while having either on a tmpfs is
> > ideal, it's not something that may be relied upon.
> 
> 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).


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.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss

Reply via email to