Re: Defect in XCU rm

[Larry Dwyer <yyyyyyyyyyy@xxxxxx>]

This misses the point I am trying to make.

A user could have a PATH that points to a directory other than one which is 
rooted under "/".  Let me try another example.

Suppose my PATH is "/../hostname/bin".  I can then run "rm -rf /" followed 
by "mkdir /bin" and
"cp /../hostname/bin/* /bin" (etc.).  This should not be precluded in the 
standard by adding a restriction to "rm" that requires it to fail if the 
user does "rm -rf /".

                Cheers,
                Larry

At 12:15 PM 3/12/2003, yyyyyyy@xxxxxxxx wrote:
> On Wed, 12 Mar 2003, Larry Dwyer wrote:
>
> > This change would preclude a useful extension to UNIX.
> >
> > There might be an implementation that allowed pathname extensions to
> > specify disk volumes or remote volumes.  Say,  a prefix to pathname
> > designates a volume, like, perhaps, "<letter>:". My search path may be, for
> > example, "C:/mksnt/mks".  My current working directory may be "A:/".  I
> > should be allowed to do "rm /" and have the expected result.
> >
> > The same argument applies if I want to have network extensions to the path,
> > such as "//<remote_machine_name>".
>
> I am fairly certain that the behavior of "//" was unspecified
> ("implementation defined?") to allow implementations to do special magic
> if they chose. This does not change the meaning of "/" as "*the*
> root" to "the root of the directory under the current tree". I am also
> fairly certain that DOS-like volume labels were not anticipated/allowed.
> DFS traditionally uses "/:/pathname" for DFS volumes where ":" is just a
> mount point controlled by the DFS client. "/" still refers to "the" root.
> Similarly, autofs implementations often use "/net/". If I have a chance,
> and if no one else can remember off the top of their head, I will dig
> through the standard and see just what is currently allowed.
>
> So, special casing "rm -rf /" does not prohibit volume designations. The
> practice of making volume designations "just another file" fits better
> into the UNIX model. That being said, I am not sure I like the idea of the
> change; I simply do not think the object is valid.
>
> < ... trimmed ...>