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@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