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

[John Reagan]

On Friday, February 5, 2016 at 7:55:04 PM UTC-5, Kerry Main wrote:
> > -----Original Message-----
> > From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> > John Reagan via Info-vax
> > Sent: 05-Feb-16 10:53 AM
> > To: info-vax at info-vax.com
> > Cc: John Reagan <>
> > Subject: Re: [New Info-vax] Container files are set to grow in importance
> > on the IT road ahead
> > 
> > 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.
> 
> Re: priv's enabled .. yeas, was using SYSTEM to install GNV
> 
> Btw, what do you mean when you say GNV stopped doing that? 
> 
> This happened approx. 2 weeks ago using the latest GNV kit.
> 
> HP-i64vms-gnv-v0300-001-1.zip
> 

Was that fresh install or an "upgrade" for a prior version?

Looking at the PSX$UP_STARTUP.COM file, the code that makes the mount points is commented out in the version I'm looking at.

$! Generate /bin... Maybe, WITH an architecture specific root
$! call create_root_directory "bin" true 'aroot'
$
$! Generate /etc
$! call create_root_directory "etc" false 'aroot'
$
$! Generate /include
$! call create_root_directory "include" false 'aroot'
$
$! Generate /lib
$! call create_root_directory "lib" false 'aroot'
$
$! Generate /man
$! call create_root_directory "man" false 'aroot'
$
$! Generate /usr... WITH an architecture specific root
$! call create_root_directory "usr" true 'aroot'
$
$! Generate /tmp
$! call create_root_directory "tmp" false 'aroot'
$
$! Generate /doc
$! call create_root_directory "doc" false 'aroot'
$
$! Generate /home
$! System managers may place user's home directories under here
$! They may want to delete this and generate a symlink to 
$! such a directory.
$!! call create_root_directory "home" false false

and later in the file

$!************************************************************************
$! Customers who want this can remove the comment mark, but do beware
$! that as written it may mount undesired devices.  In particular,
$! one should first verify on your system that it does not create
$! a directory structure loop.
$!************************************************************************
$
$!! call DoMountPoints