Actually, there's no guarantee that //host/share/... is "rooted under
slash". By definition, the meaning of // is unspecified by the standard.
Larry's point is that a reasonable implementation of Unix in an
environment supporting such a "superroot" might be for the system itself
to boot from //somewhere and for all the files required by the
steady-state operation of that system to come from //somewhere-else. In
such an environment, "rm -fr /" is a perfectly sensible operation that
poses no danger whatsoever to the running system image. I will admit
that we're on shakey ground during the period when /dev/null and
/dev/tty do not exist.
The proposed change would preclude an implementation of this nature. For
that reason alone, I'm inclined to reject it.
-----Original Message-----
From: yyyyyyy@xxxxxxxx [mailto:yyyyyyy@xxxxxxxx]
Sent: Wednesday, March 12, 2003 1:59 PM
To: Larry Dwyer
Cc: yyyyyyyyyyyyyyy@xxxxxxxxxxxxx
Subject: Re: Defect in XCU rm
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 ...>
>
>
|