[arch-projects] [initscripts][RFC] managing /tmp

[Dave Reisner]

On Wed, May 18, 2011 at 07:29:49PM +0200, Tom Gundersen wrote:
> On Wed, May 18, 2011 at 7:24 PM, Dave Reisner <d at falconindy.com> wrote:
> > I can only think of 1 reason that would happen, and it's completely
> > ridiculous: If you bind mount things into /tmp, then recursively
> > deleting /tmp would nuke things on the mounts as well. I don't think
> > there's a legitimate case for this though.
> >
> > rm does not follow symlinks, and my only other concern would be what
> > happens when nullglob is set and the glob fails to expand-- but a quick
> > test shows that not be a concern either.
> 
> Yes. I tried all these things, and it is (as far as I can tell) no way
> to exploit this. So we don't need to take this into consideration.
> 
> The only reason to don't touch /tmp is that a) the less we do, the
> better b) in 99.99% of all cases it will be a noop anyway c) in the
> remaining cases there were some users who requested to be able to
> control the behavior, so why not oblige them ;-) (but they'll have to
> do it themselves in rc.local).
> 
> -t

I disagree. Arch doesn't push any default setting of mounting tmpfs on
/tmp, so I think the majority use case is that the rm call removes
something. The opt-in behavior (the edge case) is where this becomes
a NOOP.

Additionally, clearing /tmp in /etc/rc.local is too late. Daemons are
already started at this point. X might even be running. We can't blindly
rip out this data. If we really wanted to go this route (and I
personally don't think we should), we would need to add another hook
within rc.sysint shortly after root is remounted rw, which would be the
appropriate time for this to happen.

dave