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 ([email protected]) 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
_______________________________________________
fhs-discuss mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/fhs-discuss

Reply via email to