On Tue, 11 Mar 2003, John Beck wrote:
> evought> OK, I agree that this can be an opportunity to make a serious
> evought> mistake. However, I would not be so quick to assume that there is
> evought> no plausible reason to delete everything under slash. I admit it
> evought> is a stretch, but not implausible. The stated purpose of rm is to
> evought> delete files. The stated purpose of -rf is to do so recursively
> evought> and without question.
>
> I have run across many instances of this happening by accident. The only
> instance of this happening on purpose was someone who was about to reinstall
> a machine anyway and thought "I wonder how far this would get before it
> explodes." To my thinking, that means implausible. Moreover, for someone
> with true suicidal tendencies, "rm -rf /*" would still be available.
>
> evought> More to the point, perhaps, your example is one of a whole host
> evought> of possible user errors, including "rm -rf /usr/$SUBDIR" or "rm
> evought> -rf /$SUBDIR/*" which your proposal does not help with.
>
> Those are not unique, and by themselves are more or less recoverable. There
> is only one root, however, and its destruction is not recoverable. Also,
> quoting from one of my colleagues in our internal discussion of this:
>
> It also seems reasonable to treat "/" as special, because shell
> scripts simply don't say things like:
>
> rm -rf /usr/lib
>
> It is similar to the debate about whether NULL pointers are different
> than other bad pointers. In theory they're not, but in practice the
> NULL case is so overwhelmingly more common a failure mode than, say,
> 0x37ab9, that it seems reasonable to call it out as a special case
> if doing so facilitates debugging or prevents customer pain.
Well... some of this crosses over between POSIX/UNIX, but in general, you
cannot delete active mount points. "/" is obviously an active mount point.
"rm -rf /", however, does not realize that it cannot delete its target
until after it gets done deleting the contents. I have seen this behavior
with mount points where rm goes through the whole process and then says
"I'm done; By the way, you're not allowed to do that." The failure mode
leaves something to be desired. It is generally considered good practice
for a tool to do the whole job or fail, not do half a job.
From that point of view, I can see a concrete statement about "rm -rf /"
making sense. It is already something the user is not allowed to do. You
would simply be requiring that the attempt would fail *before* data is
destroyed rather than after.
-- checkpoint
Taking that a little further (and onto thinner ice), would it make sense
to specify that, if the target directory cannot itself be deleted (for
whatever reason) then rm will not recurse into it? Again, the call will
fail. It is just a question of when.
> evought> Also, the destruction is limited to what the process has permissions
> evought> to delete. A careful user has options to prevent such catastrophes,
> evought> including error checking, limitations on permissions and chroot
> evought> prisons.
>
> Yes, but the whole point is to add a fall-back safeguard for careless
> programmers. The costs to our customers and to us internally, just from
> incidents that I know of, have been staggering.
>
> evought> On the other hand, it could be said that the result of "rm -rf /" is
> evought> "undefined" even if the implementation *does* allow it, especially
> evought> once rm gets around to stomping on the system shared libraries ;).
>
> In a hypothetical world where I was emperor, I would disallow this, period.
> Recognizing, however, that reasonable people can disagree :-) I would be
> perfectly happy with "undefined".
>
> -- John
>
>
|