[Info-vax] Container files are set to grow in importance on the IT road ahead

[John Reagan]

On Friday, February 5, 2016 at 8:50:06 AM UTC-5, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of hb
> > via Info-vax
> > Sent: 04-Feb-16 12:03 PM
> > To: info-vax at info-vax.com
> > Cc: hb <end.of at inter.net>
> > Subject: Re: [New Info-vax] Container files are set to grow in importance
> > on the IT road ahead
> > 
> > On 02/04/2016 03:40 PM, Craig A. Berry wrote:
> > > On 2/4/16 7:54 AM, Kerry Main wrote:
> > >>> -----Original Message-----
> > >>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf
> > Of hb
> > >
> > >>> Hard links do not point from one disk to another. So something else
> > was
> > >>> used by GNV.
> > >
> > >> Well, there must be a hard or soft link of some sort because after the
> > >> fact,
> > >> I did a dir... on all the non-system disk GNV sub directories and a
> > >> number
> > >> of system dir's showed up. Hence, the original delete/tree cmd
> > continued
> > >> deleting on the system disk.
> > >
> > > It's possible that the POSIX root business and related mount points are
> > > what you tripped over.  If you figure out how those things work, please
> > > explain them to me :-).  I don't know if "SET NOROOT" or "SET ROOT
> > NL:"
> > > might've prevented the disaster, but they'd be worth a try.  Or umnt
> > on
> > > whatever mount points were aimed at your system disk, if any.
> > >
> > 
> > It's all open source so it is easy to understand :-) I know nothing
> > about these mount points and mnt/umnt. I would expect mnt to mount
> > any
> > VMS directory into the POSIX file system tree. The output of mnt seems
> > to support this:
> > bash-4.3$ mnt
> > DISK$ODS5_1:[VMS$COMMON.gnv]usr.DIR;1 on /usr
> > DISK$ODS5_1:[VMS$COMMON.gnv]man.dir;1 on /man
> > DISK$ODS5_1:[VMS$COMMON.gnv]lib.DIR;1 on /lib
> > DISK$ODS5_1:[VMS$COMMON.gnv]include.dir;1 on /include
> > DISK$ODS5_1:[VMS$COMMON.gnv]etc.dir;1 on /etc
> > DISK$ODS5_1:[VMS$COMMON.gnv]bin.DIR;1 on /bin
> > bash-4.3$
> > So I can think of an environment where the POSIX root is in a
> > sub-directory of the installed GNV kit - on a non-system disk, and a
> > (default/customized?) mount point under the root mounts a directory
> > from
> > the system disk. I didn't try but it is quite possible that a VMS DIR
> > and/or DELETE will follow the mount points (which in the SHOW ROOT
> > directory look like directories - as far as I can see) from the
> > non-system disk to the system disk.
> > 
> > I really would like to know how the directory structure was, before it
> > was deleted. And I still think that DELETE/TREE is innocent, here, as a
> > "normal" DELETE with "..." would have done the same damage.
> 
> Just to clarify - I also do not believe the delete/tree has an issue. 
> 
> It is much more likely due the way the GNV kit is setup with hard/soft
> links and the fact that I installed the kit on a non-system disk.
> 
> Having stated this, it is a big wake-up call (for me anyway) as I would
> never have expected a delete/tree cmd on a non-system disk to go off
> and start deleting many system files on the system disk .. when $ Help xxx 
> says something to the effect "file not found", you know you are in trouble.

Yep and GNV stopped doing that.  It wasn't good to put indirect access to system files from the non-system disk.  However, you must have done that DEL/TREE with privs enabled, right?  The standard protection checks would prevent a non-priv'd user from deleting those files regardless of how you got there.