Mark> What exactly is being proposed in this defect report ?
If an rm implementation was to, when detecting that an operand resolves
to "/", then print an error and exit, removing nothing, it would violate
the spec. The proposal is that the spec be clarified to allow this, or
at least not to disallow it.
Mark> Writing scripts like this without checking
Mark> the integrity of the variable(s) is just flawed programming.
Yes, that is exactly what we're trying to protect against.
Mark> As for the statement "There is only one root": With the chroot
Mark> command, aren't there many "root"s ?
Yes, of course, one for each.
Mark> I would think it quite reasonable to see a
Mark> "rm -rf /" after a chroot command.
I disagree; again quoting one of my colleagues
in any rational programming model, the parent would clean up after
its chroot'ed children exited. It would not just spawn children
and count on them to eventually self-immolate. In any case, the
practical difficulties in using chroot() successfully limit its
application to a handful of specialized applications.
Mark> As for a suggestion that "rm -rf" should either do the whole job or
Mark> fail: Well, that's a nice concept but its not a practical suggestion
Mark> for the rm command. The existing behaviour is too entrenched. I don't
Mark> think its feasible to change that now. Wouldn't this idea be better
Mark> suited as a new utility (and/or api's).
You're missing the point: a planned modification to rm to prevent accidental
destruction of the entire file system. No new utility and/or API would do
the trick, by definition, since it is "death by rm" that we are explicitly
trying to safeguard against.
-- John
|