I would agree that the effect of doing "rm -rf /" will not remove
the '/' directory. But it should still remove as much as possible
from the contents within '/'.
(ie " rm -rf / " is equivalent to " rm -rf /* ")
What exactly is being proposed in this defect report ?
That "rm -rf /" could be implemented as a no-op ?
Just to solve the case of "rm -rf /$var/" when $var is empty or
undefined ?
I don't think this is worth special casing.
What about the unintentional
rm -rf /$var/*
What is being proposed for this case ?
Writing scripts like this without checking the integrity
of the variable(s) is just flawed programming.
As for the statement "There is only one root":
With the chroot command, aren't there many "root"s ?
I would think it quite reasonable to see a "rm -rf /"
after a chroot command.
As for a suggestion that "rm -rf" should either do the whole job or
fail:
Well, that's a nice concept but its not a practical suggestion for the
rm command.
The existing behaviour is too entrenched. I don't think its feasible
to change that now.
Wouldn't this idea be better suited as a new utility (and/or api's).
mark
> -----Original Message-----
> From: John Beck [mailto:yyyyy@xxxxxxxxxxx]
> Sent: Tuesday, March 11, 2003 2:13 PM
> To: yyyyyyy@xxxxxxxx
> Cc: yyyyy@xxxxxxxxxxx; yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
> Subject: Re: Defect in XCU rm
>
>
> 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.
>
> 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
>
|