NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/os/vms/20238

Internet Message Format | 1993-01-03 | 8.4 KB

Path: sparky!uunet!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: re: Re: HELP!!! Security problem for gurus. [Directories]
Date: 3 Jan 1993 09:58:58 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 141
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>,<[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] writes:
=>Interesting.  The ODS-II specs, as best I can recall, define two possible
=>entry types:  Files and links.  Files are what you would expect.  A link is
=>a like a Unix "soft link":  A text string that replaces the file specifica-
=>tion being parsed.  While specified way back when ODS-II was first designed
=>(i.e., when VMS was designed), this feature has never been implemented.
=
=Being unfamiliar as I am with the specific behavior of "a Unix 'soft link',"
=can you elaborate on the intended behavior of this interesting-sounding
=never-implemented feature?  I'm just wondering what we're missing out on.

OK.  A normal directory entry contains a file name and a file ID.  This allows
directory lookups to find the file header.  It also means that the file must
exist on the same disk (or at least in the same volume set) as the directory
entry.  A link, on the other hand, consists of a file name and a string
containing the *REAL* name of the file.  The real name is intended to include
the device name.  So, for example, you could have a directory entry on DUA0
that associated the name FOO.BAR in the directory [SOMETHING_OR_OTHER] with a
file name like DUA1:[SPAM]SOME_OTHER.FILE_NAME.  Then, if you tried to open
file DUA0:[SOMETHING_OR_OTHER]FOO.BAR, RMS (or the disk ACP) would
transparently open the file DUA1:[SPAM]SOME_OTHER.FILE_NAME for you.
=
=Very interesting!  What's a "hashed" file type?  Again, can you elaborate?
=This may be a loaded question, but: how does it happen that features can
=BE "spec'd but never implemented?"

A specification (either rather vague or quite specific) is written and,
sometimes, fields allocated in data structures in order to allow for the future
implementation of the feature.  A good example of this is file ACLs:  There was
a somewhat general specification for them as early as 1978, and file headers
had fields in them to allow the implementation of this feature, but it wasn't
until VMS version 4 that it was actually implemented.

=What determines whether a particular
=feature gets implemented right away, or after a long delay (how long has
=ODS-II been in existence with spec'ed-but-never-implemented features?),

It's been in existence for something like 15 years now with such features.  How
soon they're implemented depends on how important DEC considers the features.
I fear that links will never be implemented, since DEC has implemented volume
sets and seems to believe that they're sufficient for dealing with directories
that span volumes.

=or never?  And, finally, how do YOU find out about these things, Jerry?
=Inquiring minds... etc. ;-)

I don't know how Jerry found out, but in my case, I had a disk that held
important data that hadn't yet been backed up fail.  Someone connected an
(unkeyed) cable upside-down, which caused the system to overwrite part of the
disk when it tried to mount it.  In an effort to recover the data, I started
reading through a specification of ODS-2 that my predecessor had lying around.
Unfortunately, the day he photocopied the manual, the fuser on the photocopier
was running at below the proper temperature, and the print was rubbing off the
pages.  In order to guarantee that I'd have a legible copy next time I wanted
one, I typed the whole thing into the computer.  In the process of trying to
decipher the parts that were on the verge of illegibility, I learned more about
ODS-II than I thought I'd ever want to know (ever wonder about the actual
organization of an indexed file?).
=>    I also found that if I put an INVALID value [...] into that field
=>    in the FIRST entry in the .DIR file [...] I was able to do a DIRECTORY
=>    operation on the  directory represented by the patched .DIR file, but
=>    was UNABLE to access any of the FILES THEMSELVES.
=>
=>I believe DIRECTORY accesses the directory files directly, rather than going
=>through RMS.  It probably doesn't check the validity of the entries it sees.
=
=It seems evident from what I've observed, that DIRECTORY doesn't (currently)
=validate at least the contents of the "type" field I played with -- but I'm
=afraid I don't see how it makes any difference whether one "accesses the
=directory files directly" OR "(goes) through RMS."

Ah, that's easy.  If you don't go through RMS, you're dealing with separately
maintained code.  That means that some things RMS doesn't like might be
perfectly acceptable to DIRECTORY.

=If I open "filespec.DIR"
=as a FILE, I can read it just fine using RMS -or- "directly."  Do I mis-
=understand you, Jerry?

I think so.  If you open filespec.DIR using RMS and read it, RMS will be happy
to pass the information it gets to you, uninterpreted.  However, when you try
to open a file that's IN [filespec], RMS tries to interpret it as a directory
entry, and may not be happy with what it sees.  The (separately maintained)
code in DIRECTORY might, however, be somewhat more forgiving.

=Didn't think of that.  I can count the number of times I've done an
=ANALYZE/DISK in my six-year VMS career (four of them as a system manager
=of a very small system) on the fingers of one hand, and I don't think
=I've EVER used /REPAIR...

If you're not doing a BACKUP/RESTORE every month, then you *SHOULD* be doing an
ANALYZE/DISK/REPAIR that often.

=I remember seeing RMS bugs in the past that would delete the erring process
=upon encountering certain errors in on-disk or file structure.  I was always
=surprised to find such dramatic bugs in RMS, an otherwise extremely robust-
=seeming entity...

You shouldn't be surprised.  You see, RMS is also a *CRITICAL* entity.  If it
runs across something that it doesn't understand, there are a few
possibilities:
    1)  The disk is corrupted;
    2)  The user's address space is corrupted;
    3)  The system address space  is corrupted;
    4)  The system disk is corrupted.

Now, case 1 might not warrant a bugcheck.  Case 2 should, at the very least,
result in process deletion;  Cases 3 and 4 both warrant a system crash before
corrupted memory/system disk can do any more damage.  The idea is to have the
system fail safe:  When in doubt, do whatever's most likely to insure the
integrity of the system;  if that means getting the system manager's attention
with a >>> prompt on the console, so be it.

=>Also, the future direction of VMS seems to be
=>to forbid direct access to directory files (at least direct write access).
=>You could find your modified directory entries completely inaccessible after
=>the next upgrade!
=
=That's VERY interesting!  At what level of the system would this be imple-
=mented?  Disk driver (mark certain media blocks /NOWRITE)?  $QIO-ACP inter-
=face ("don't allow access to any file whose "I'm a directory" bit is set")?
=Write-Logical-(or-Physical)-Block $QIO request?  Blocking directory-write
=access at any level would pose difficulties and paradoxes.  For example,
=RMS needs to be able to update directories, which would seem to preclude
=blocking directory-writing at the driver or $QIO levels, but NOT blocking
=such access at those levels would hardly prevent "illegal" modifications
=in the intended manner, as simply bypassing RMS would be sufficient...
=Ah well, some combination of access-mode and file-attribute check could
=be applied that would at least make "illegal" modification MORE DIFFICULT
=than it is today.

Most likely, this would be done by implementing the access-mode checks that
Jerry referred to as an umplemented feature earlier.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen 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.