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 ...>
>
>
|