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

[Miloslav Trmac]

I don't really have a position on the overall issue of /run/user, I'd just like to get a few points clarified.

----- Original Message -----
> On Tue, 24.05.11 16:36, Roger Leigh (rleigh at codelibre.net) wrote:
<snip; re: tmpfs DoS>
> > 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...

Is FHS 3.0 supposed to be a standard for all Linux distributions, or only those running bleeding-edge kernels, init systems and other software that perhaps doesn't even exist at the time the standard is released?  Perhaps this has already been agreed upon, and I have only missed it...


[re: cleaning /tmp]
> 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.

To be fair, new bug reports from users that have lost data do appear, perhaps one every two years.  In most cases I've fixed tmpwatch to avoid the cause of the problem, and in many times it's not completely clear whether the behavior is a bug or "working as designed, user error" - but lost data is lost data.  OTOH, I currently have a 6 months old directory in /tmp that is definitely not needed, but some broken application keeps updating its file times.  I'd say tmpwatch is working well (i.e. I'm not at all worried about losing my data or running out of space), but the situation isn't quite perfect.

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

Hm, so it can happen in currently released versions?  "It's fine to say 'must'" but bugs do happen.  To the extent possible, the design should minimize the number and size of components that are required to work absolutely perfectly for security.
    Mirek