From XBD pathname resolution (4.11):
"A pathname consisting of a single slash shall resolve to the root
directory of the process. A null pathname shall not be successfully
resolved. A pathname that begins with two successive slashes may be
interpreted in an implementation-defined manner, although more than two
leading slashes shall be treated as a single slash."
As has been pointed out, sometimes it is perfectly valid to remove the
root directory for this process (particularly in the context of chroot).
What is more, existing practice is extensive in permitting it. I am
unalterably opposed to changing this.
In the context of rm -rf /$unsetvar/ we get to the possibly
implementation defined behaviors, and anything is possible!
If you want a command that won't accidentally remove the root directory,
it is not hard to make a new (and portable!) command to do so ... but
don't go breaking rm.
On Wed, 2003-03-12 at 13:58, yyyyyyy@xxxxxxxx wrote:
> On Wed, 12 Mar 2003, Larry Dwyer wrote:
>
> > 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.
>
> The point is that there *are no* directories which are not rooted under
> slash. In UNIX systems, "/" is not the "main system drive" like C: is
> under DOS/Windows. "/" is *the* root of the filesystem hierarchy. Other
> volumes are still "under the root". Other volumes, including other fixed
> drives, removable media and remote volumes (for that matter: devices,
> processes, named pipes, etc) are all rooted under slash and are not
> prevented by the current arrangement. "/media/cdrom",
> "/:/myserver/myshare", "/net/myserver/myshare", "/Volumes/Remote Homes",
> "/dev/hda", "/proc/kmem" and so forth are all allowed techniques that
> current systems use. "C:/somepath" is not one of those techniques.
>
> The single root viewpoint is central to UNIX. Allowing multiple roots is
> not a trivial change to the current standard or current systems/utilities.
> Even Macintosh, which presents multiple roots to users, is singly rooted
> in its POSIX core ("/Volumes/"). The special casing of "rm -rf /" does not
> prevent multiple roots. To the extent of my understanding, multiple roots
> are already precluded and conflict with the UNIX model.
>
> Note, that this does make the scope of an accidental "rm -rf /"
> potentially larger. If a mounted remote filesystem honors super-user
> privileges from the client, remote directories could be destroyed as well.
> This is one reason most servers are configured to not honor super-user
> privileges even from "trusted" machines.
>
> > 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 /".
>
> "/../hostname/bin" is equivalent to "/hostname/bin". I also do not see why
> "/../hostname/bin" would be any more useful that "/:/hostname/bin". If
> convenient access to the root of the current mount point is desired, that
> can be done easily within the shell through either builtin variables or
> utilities:
>
> cd $VOLUME_ROOT/
> cd `volume_root`
> cd $C/
>
> zsh already has a facility for cd'able variables such that prefixes are
> mapped against defined directory aliases and can be used in path displays:
>
> cd PROJECT_TREE/src
>
> hostname:[PROJECT_TREE]/src>
>
> > 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 ...>
> >
> >
|