hole in vms?
John E. Davis
Consider the following: (never mind the unix like stuff, not important)
/davis> mkdir t
/davis> cd t
USER$DISKA:
/davis/t> set file/enter=[davis.t]tt.dir [000000.davis]t.dir
/davis/t> ls
Directory USER$DISKA:[DAVIS.T]
TT.DIR;1
Total of 1 file.
/davis/t> dir [...]
Directory USER$DISKA:[DAVIS.T]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT.TT]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT.TT.TT]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT.TT.TT.TT]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT.TT.TT.TT.TT]
TT.DIR;1
Total of 1 file.
Directory USER$DISKA:[DAVIS.T.TT.TT.TT.TT.TT.TT]
TT.DIR;1
Total of 1 file.
Grand total of 7 directories, 7 files.
So apparantly there is a limit to the amount of subdirectories. It's a good
thing to. Now here is my question: What happens when something like backup
hits this? What about if a user does something like:
$ set file/enter=[davis]root.dir [000000]000000.dir
Does backup and other utilities know that these are just aliases and should be
skipped? I saw nothing in $ dir/full to indicate otherwise.
Just curious...
--
_____________
#___/John E. Davis\_________________________________________________________#
# #
# /\/\/\ internet: da...@amy.tch.harvard.edu #
# /\/\/\/\ bitnet: davis@ohstpy #
# \/\/\/\/ office: 617-735-6746 #
# \/\/\/ #
#___________________________________________________________________________#
# #
Paul S. Winalski
In article <DAVIS.92A...@shasta.bu.edu>,
da...@shasta.bu.edu ("John E. Davis") writes:
|>
|>Consider the following: (never mind the unix like stuff, not important)
[omitted example showed a circular subdirectory tree created by doing a
SET FILE/ENTRY of a .DIR file in itself]
|>
|>So apparantly there is a limit to the amount of subdirectories.
Yes. RMS stops at 8 levels total (modulo tricks such as rooted directories).
|>It's a good
|>thing to.
Many feel that the 8-level limit is too restrictive. It's not enough for some
applications.
|> Now here is my question: What happens when something like backup
|>hits this? What about if a user does something like:
|>
|>$ set file/enter=[davis]root.dir [000000]000000.dir
|>
|>Does backup and other utilities know that these are just aliases and should be
|>skipped? I saw nothing in $ dir/full to indicate otherwise.
BACKUP/FULL of course doesn't care because it is driven off the index file
rather than the volume directory structure. In the experiment I conducted,
the command:
BACKUP/LOG [DAVIS...] [DIR]X.SAV/SAVE
did not result in the copying of [000000] or anything under it to the save
set. Apparently BACKUP has logic to detect and avoid this situation.
--PSW
Carl J Lydick
>thing to. Now here is my question: What happens when something like backup
>hits this? What about if a user does something like:
>
>$ set file/enter=[davis]root.dir [000000]000000.dir
>
>Does backup and other utilities know that these are just aliases and should be
>skipped? I saw nothing in $ dir/full to indicate otherwise.
>
>Just curious...
Any utility that scans the directory tree will process these files many times.
This includes non-image backups. However, BACKUP/IMAGE scans INDEXF.SYS rather
than the directory tree, so it only processes them once. I'm not sure about
BACKUP/FAST.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CA...@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
Disclaimer: Hey, I understand VAXes and VMS. That's what I get paid for. My
understanding of astronomy is purely at the amateur level (or below). So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it. If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Carl J Lydick
Apparently you weren't creative enough in your experiment, or you're running a
later version of VMS than I am (5.4-2):
$ create/dir [.foo]
$ set file/enter=[.foo]foo.dir;1 []foo.dir;1
$ create [.foo]spam.
$ backup/log [.foo...] test.bck/save
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO.FOO.FOO]FOO.DIR;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO.FOO]SPAM.;1
%BACKUP-S-COPIED, copied $1$DIA0:[CARL.FOO]SPAM.;1
Avatar
da...@pacific.mps.ohio-state.edu (John E. Davis) writes...
> In article <1992Apr21....@e2big.mko.dec.com>,
> wina...@tle.enet.dec.com (Paul S. Winalski) writes...
>
> Hmm. I am running VMS V5.5, so that may make a difference. It also may
> be that 000000.DIR is treated differently from other subdirectories. The
> results that you got certainly match what I would have expected. I was
> surprised when BACKUP skipped [.000000...] when I ran my experiment.
>
>Perhaps backup has an implicit /exclude=[.000000...] in it. Anyone know for
>sure?
By using the VERB command, I was able to extract and view the BACKUP
definition from my command table file:
--
!************************************BACKUP*************************************
[..irrelevant information witheld..]
define verb BACKUP
image BACKUP
parameter P1 , label=INPUTS , prompt="From"
value (required,list,type=$infile)
parameter P2 , label=OUTPUTS , prompt="To"
value (required,list,type=$outfile)
[..irrelevant information witheld..]
qualifier EXCLUDE
value (required,list,type=$infile)
[..irrelevant information witheld..]
--
As can be seen, BACKUP does _not_ have an implicit/exclude=[.000000...]
within
IMHO, it might not be such a good idea to conduct such an experiment;
creating directory loops cannot possibly be "good" for your system, and may
cause serious damage. You may want to consult your sysops before proceeding
any further -- I'm sure they would prefer to simply answer your question(s)
rather than have to reboot the system. ;-)
.
.' `.
___________________________________.'-{*}-`.____________________________________
Zerxes M. Bhagalia '---------` INT: v064...@ubvms.cc.buffalo.edu
State University of New York .---------------. v064lnev@ubvms (bitnet)
at Buffalo .' `. bha...@acsu.buffalo.edu
Recovering Engineer .' `. Director, News Information
Computer Science .'________MDCCLXXVI________`. Division, WFFT 104.9 FM
---------------------N O V U S O R D O S E C L O R U M----------------------
Don Stokes
> By using the VERB command, I was able to extract and view the BACKUP
> definition from my command table file:
> within
Ummm -- I think you'll find that the command definition is about the _last_
place such a test would be found.
A quick search through BACKUP.EXE reveals one occurrence of the string:
[000000]000000.DIR;1
Also note that the root directory is _always_ file index number 4 (ie file
id (4,4,n)), so such a test needn't even do a filename search.
For the curious, no, BACKUP/FAST does not do the right thing with such
directories. (BACKUP/IMAGE does, however.)
--
Don Stokes, ZL2TNM (DS555) d...@zl2tnm.gen.nz (home)
Network Manager, Computing Services Centre d...@vuw.ac.nz (work)
Victoria University of Wellington, New Zealand +64-4-495-5052
Jim Kellerman
da...@pacific.mps.ohio-state.edu ("John E. Davis") writes:
|> Path:
hollie.rdg.dec.com!news.crl.dec.com!deccrl!decwrl!sun-barr!cs.utexas.edu
u!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!davis
|> From: da...@pacific.mps.ohio-state.edu ("John E. Davis")
|> Newsgroups: comp.os.vms
|> Subject: Re: hole in vms?
|> Message-ID: <DAVIS.92A...@pacific.mps.ohio-state.edu>
|> Date: 21 Apr 92 20:19:44 GMT
|> References:
<DAVIS.92A...@shasta.bu.edu>,<1992Apr20.2...@e2big.mko.dec.com>
|> Sender: ne...@pacific.mps.ohio-state.edu
|> Reply-To: da...@pacific.mps.ohio-state.edu (John E. Davis)
|> Organization: "Dept. of Physics, The Ohio State University"
|> Lines: 20
|> In-reply-to: wina...@tle.enet.dec.com's message of 21 Apr 92 16:30:21 GMT
|>
|> In article <1992Apr21....@e2big.mko.dec.com> wina...@tle.enet.dec.com
(Paul S. Winalski) writes:
|> [......]
|> Hmm. I am running VMS V5.5, so that may make a difference. It also may
|> be that 000000.DIR is treated differently from other subdirectories. The
|> results that you got certainly match what I would have expected. I was
|> surprised when BACKUP skipped [.000000...] when I ran my experiment.
|>
|> Perhaps backup has an implicit /exclude=[.000000...] in it. Anyone know for
|> sure?
I would expect backup to exclude a [.000000] directory. Remember that there is a
directory entry
in [000000] for 000000.dir (i.e., [000000]000000.dir;1)
Ehud Gavron 602-570-2000 x. 2546
v064...@ubvmsb.cc.buffalo.edu (Stupid Nickname) writes...
#In article <DAVIS.92A...@pacific.mps.ohio-state.edu>,
# da...@pacific.mps.ohio-state.edu (John E. Davis) writes...
#> In article <1992Apr21....@e2big.mko.dec.com>,
#> wina...@tle.enet.dec.com (Paul S. Winalski) writes...
#>
#> Hmm. I am running VMS V5.5, so that may make a difference. It also may
#> be that 000000.DIR is treated differently from other subdirectories. The
#> results that you got certainly match what I would have expected. I was
#> surprised when BACKUP skipped [.000000...] when I ran my experiment.
#>
#>Perhaps backup has an implicit /exclude=[.000000...] in it. Anyone know for
#>sure?
#
# By using the VERB command, I was able to extract and view the BACKUP
#definition from my command table file:
..
# qualifier EXCLUDE
# value (required,list,type=$infile)
..
#
# As can be seen, BACKUP does _not_ have an implicit/exclude=[.000000...]
#within
As can be seen, just because someone gave you a copy of VERB doesn't
mean you can think straight.
BACKUP can be trained (and is) to ignore the [.000000]tree when doing
[...] lookups. It is in the program image and not in the command
language definition. If it was in the CLD, then if you DID specify
a /EXCLUDE qualifier, it would override and ignore the implicit [.000000]
one. This would be a no-no, and therefore it's in the image.
# IMHO, it might not be such a good idea to conduct such an experiment;
#creating directory loops cannot possibly be "good" for your system,
IMHO you should not confuse magic and computers. "Cannot possibly be 'good'
for your system" is as stupid a phrase as I've ever heard. Either tell us
why this will negatively impact my system or don't, but don't say it can't
possibly be good.
#and may cause serious damage.
Like what, making my temper flare?
# You may want to consult your sysops before proceeding
#any further -- I'm sure they would prefer to simply answer your question(s)
#rather than have to reboot the system. ;-)
YOU might want to consult YOUR sysops before posting any more stupid
ideas. I'm sure they would prefer to simply answer every stupid question
any user comes up with before he or she issues a simple DCL command
than rushing to reboot the system (which wouldn't affect the file
link anyway.)
#Zerxes M. Bhagalia '---------` INT: v064...@ubvms.cc.buffalo.edu
#Recovering Engineer .' `. Director, News Information
^^^^^^^^^^
Take more time off.
Ehud
--
Ehud Gavron (EG76)
gav...@Spades.ACES.COM
When you're cool, the world bores you.
David Woodruff, 253-6943, Room 26-407
able to get past. I didn't breathe easy till the disk was re-initialized.
Dave
*******************************************************************************
"Call me Ishmael. Some years ago-- never mind how long precisely-- having
little or no money in my purse, and nothing particular to interest me on shore,
I thought I would sail about a little and see the watery part of the world."
David S. Woodruff, MIT Lab for Nuclear Science, (617)253-6943
d...@mitlns.mit.edu, BITnet: dsw@mitlns FAX (617)258-6923
DE...@u.washington.edu
>What about if a user does something like:
>
>$ set file/enter=[davis]root.dir [000000]000000.dir
>
>Does backup and other utilities know that these are just aliases and should be
>skipped? I saw nothing in $ dir/full to indicate otherwise.
What happens? The user has a pointer to the MFD in his home directory. This
*shouldn't* give him access to any other files, but... I seem to remember
running across a bug in which DIRECTORY would show me all files on the
disk as though they were "in" my login directory. (I was using a rooted
logical name at the time. I wonder if this has been fixed...)
Anyway, this brings to mind some potential problems for the unwary system
manager. What follows are a couple of cautionary tales... :)
The VAX computers I work with are used mainly by a student population who
don't, in general, know a great deal about how VMS works. Occasionally one
person will learn a number of neat "tricks" that VMS supports. For example,
one student wrote a DCL command procedure which, besides drawing a picture,
set ACLs granting the author unlimited access to all of the user's files,
including the login directory. Novice students are often suckered into this.
Another common thing to do is to grant world write access to the user's login
directory.
One wonders why this would be of interest since we have disk quotas on our
disks. Well, we had *some* students who liked to play mind-games with novice
users. One neat trick was to put a file into the novice's directory. The
novice often wouldn't notice the file until (s)he needed to recover some
disk space. Surprise! The user "has" a file they cannot delete! Oh no!
Ha! Ha! What fun!
Later, several of these advanced students colluded to put files in each other's
directories. (They used an editor which had EXQUOTA to do this.) Again,
why would they want to do this???
Well, we used to have a system manager who liked to do some "disk
cleanup" on a quarterly basis. This consisted (in part) of running VERIFY
(ANALYZE /DISK /REPAIR) on all of the user disks. What is "wrong" with this?
Well.... when VERIFY encounters a file owned by a UIC which does not have a
quota entry for that volume, it creates an entry for that UIC. Granted, it
only gives a quota of 100 blocks, but when it happens on several disks
it adds up. That, however, is not the end of *this* story.
There were complications. It also happened that users would, on occasion,
"lose" their disk quota. This was due to an early VMS bug which occurred
when the QUOTA.SYS file had to be extended. Somehow, QUOTA.SYS would "lose"
the new extent, and users would lose their quota. To combat this problem,
we had software which compared, on a nightly basis, the quotas reported by
DISKQUOTA with our records, and repaired any discrepancies. This was great
because it also fixed users who somehow managed to raise their quotas.
(There were security bugs back in those days.) Unfortunately, this software
assumed that the user would only have a quota on one disk. Guess what.
After VERIFY ran, it "fixed" quotas on EVERY disk the user managed to get a
file on. Thus, "tricky" users could easily triple, quadruple, our quintuple
their available disk space. :)
Now, remember that poor novice who has a file that cannot be deleted? There
was a solution to this problem, too. After analyzing all of the disks, the
following command was executed:
$ SET FILE [*...]*.*;* /OWNER=PARENT
Now the user could delete that nasty file. Any ideas how this could be
used? Now, I don't recall anyone ever placing a pointer to the MFD in their
login directory, but what a problem THAT could cause. No, we had clever
users. Instead of making themselves noticed, they relied on alphabetization.
One of our "worst" offenders discovered that his home directory was on the
same disk as the "games" directory. (Access to games was regulated based
on the time of day and the number of users. When "closed", the games were
protected to prevent world access.) The games directory was named GA99.DIR,
and this user's directory was named something like TExx.DIR. One day, while
the games were open, he created links to several of the games using the
SET FILE command. And then he waited until the following quarter break.
Guess who owned all of the games he wanted? Guess who copied them all to tape?
Guess who restored them with different names? Guess who played games all
quarter long?
As a result of these "problems", the disk analysis procedure was changed to
do the SET FILE command first, and then an ANALYZE /DISK. In fact, we don't
run that procedure anymore. The disk quota reconciler, by the way, was also
fixed. Now, we have what might be thought of as a "system-wide disk quota".
If the users wish to place files on other disks, it's not a problem.
Thinking about all of this has made me laugh. I hope it brings other some
mirth, too, as well as an inkling that privileged operations should not be
done thoughtlessly.
-Derek S. Haining
University Computing Services
University of Washington
Seattle, Washington 98195
(206) 543-5579
DE...@MAX.BITNET
DE...@MAX.U.WASHINGTON.EDU