PM@uwovax.UWO.CDN.UUCP (11/25/87)
We are running a VAX cluster. We run a cluster wide print queue that uses the CMU-TEK IP package to ship the print files to a Ultrix lpd deamon that feeds a laser printer. Normally files put into the queue arrive properly at the other end. Everything works just fine. If I try to send a file like SYS$HELP:FINGER.HELP then the CMU symbiont fails complaining that it can't find the file. The file that it is looking for is _HSC001$DUA0:[SYSCOMMON.SYSHLP]FINGER.HELP and if you try to type that file, sure enough the directory is bad. It should be something like _HSC001$DUA0:[SYS0.SYSCOMMON.SYSHLP]FINGER.HELP (i.e. SYSCOMMON is not a top level directory). When I print the same file to the standard SYS$PRINT queue it "says" that it is printing the file named by the illegal directory specification (on the header page), but it actually finds the right file. This looks like a problem with the expansion of logicals, but what is the standard print symbiont doing to make it work? Is this situation just an artifact of our specific logical name setup on our cluster or is it a more general problem? Any help to untangle the logicals web, or to tell me that we are not alone would be appreciated. A work around would be great! --- Peter Marshall, Data Comm. Manager CCS, U. of Western Ontario, London, Canada N6A 5B7 (519)661-2151x6032 pm@uwovax.BITNET; pm@uwovax.uwo.cdn; Peter.Marshall@uwo.cdn peter@julian.uucp; ...!watmath!julian!peter
LEICHTER@VENUS.YCC.YALE.EDU.UUCP (11/27/87)
We are running a VAX cluster. We run a cluster wide print queue that uses the CMU-TEK IP package to ship the print files to a Ultrix lpd deamon that feeds a laser printer. Normally files put into the queue arrive properly at the other end. Everything works just fine. If I try to send a file like SYS$HELP:FINGER.HELP then the CMU symbiont fails complaining that it can't find the file. The file that it is looking for is _HSC001$DUA0:[SYSCOMMON.SYSHLP]FINGER.HELP and if you try to type that file, sure enough the directory is bad. It should be something like _HSC001$DUA0:[SYS0.SYSCOMMON.SYSHLP]FINGER.HELP (i.e. SYSCOMMON is not a top level directory). When I print the same file to the standard SYS$PRINT queue it "says" that it is printing the file named by the illegal directory specification (on the header page), but it actually finds the right file. This looks like a problem with the expansion of logicals, but what is the standard print symbiont doing to make it work? Is this situation just an artifact of our specific logical name setup on our cluster or is it a more general problem? Any help to untangle the logicals web, or to tell me that we are not alone would be appreciated. A work around would be great! The problem isn't in the logicals; it's a subtle problem with the way the spooler interacts with the file system. What happens is this: When you spool a file, what gets recorded in the queue is the file id of the file. Later, when the symbiont accesses the file, it uses the file id. The reason for this is simple: File id's don't change, while file names and directories do. Using the file id ensures that if you print file "FOO.FOO" and later change its name to "A.B", the queue system can still find it. Even more fundamentally, it means that it is possible to spool files that are not entered in any directory. MAIL does this when you use its PRINT command; spooled devices do the same thing - when you copy to LP:, you are really copying to a file, but you'll never find that file in any directory. (That's not to say this scheme is without disadvantages. For example, you can't PRINT a file on another DECnet node - such a file can't be described by any local file id. And you can't SUBMIT a job for later, then decide to edit the command file - it will be your original command file that gets used, not your new version.) So, what has this got to do with your problem? Well, when the symbiont wants to print the name of the file, it needs to translate back from the file id to the file spec. This is usually possible: The file header contains a copy of the file name and type, and the file id of the directory the file is entered in, if any. The file id of the directory can, in turn, be translated into a file name and type, and another directory pointer; and so on until we reach the MFD, directory [000000] (which points back to itself). All that is fine, as long as the mapping from (full) file specs to file id's is one-to-one. But it needn't be: SET FILE/ENTER can create a synonym: A second name for the same file (file id). There's no real distinction between the two, but only one can appear in the "file name" portion of the file header. As best I can recall, SET FILE/ENTER leaves the current entry alone. RENAME, of course, changes the entry - whether it does so only when it matches the old file entry, I don't know. In any case, it is quite possible for the file name in the header to specify a value that is not the only possible name for the file, or even a name that doesn't exist - because of a SET FILE/REMOVE for example. The directory backlink is a file id, not a name, so slightly different limits exist. However, since it IS possible to delete a directory, it is possible for the backlink to point to a file that no longer exists. Further, in generating a full file spec, the name of the directory will be needed - and getting THAT requires going through the same process as getting the file's name, and is subject to the same foibles. On a cluster-common system disk, certain directories are given aliases. It's been a while since I look at this, and I don't remember how it is all laid out, but some of the directories appear at multiple levels. The problem is that the directory back-pointers can get "out of sync", and point to levels where nothing really exists. There's actually a simple fix: Do an ANALYZE/DISK/REPAIR/CONFIRM on your system disk. ANALYZE/DISK will complain about back-pointers that don't match (i.e., it will compare the back-pointer it finds in the header to the path it took through the directory tree to find the file). When a file has a synonym, at least one of the paths to the file must be "incorrect", as far as ANALYZE/DISK is concerned. The "repair" it will undertake, if you ask it to, is to make the back-pointer match the path it took. In the case of a cluster- common system disk, every ANALYZE/DISK/REPAIR will simply exchange the back- pointers. Normally, you should use /CONFIRM and NOT let ANALYZE/DISK do this. What's happened is that you've done an - or an odd number of - such "repairs", so your pointers are now "incorrect". What you need to do is a /CONFIRM pass, and look closely at what ANALYZE/DISK wants to do. Then approve the "repair" only when it makes the pointers agree with what makes sense. Presumably, the CMU-TEK code is looking at the back-translated name of the file and getting confused. Once you've straightened out the directory back- links, the problem will probably go away. -- Jerry
rrk@byuvax.bitnet (12/02/87)
Your message demonstrates three things:
1. VMS $sndjbc system service must have a bug concerning concealed devices.
I have seen it treat concealed devices correctly. It would take some
work on the system to determine exactly why yours isn't getting parsed
correctly.
2. (Already known to me) a 28-byte structure is communicated by $sndjbc
by which it can easily open the file without a file name. This includes:
(16 byte) device id, (6 byte) directory id (for removing directory entry
on auto-delete, I guess), (6 byte) file ID. This is used by DEC's
symbionts, instead of file name, to open files. THE ONLY SECURE WAY
TO WRITE A SYMBIONT IS TO OPEN FILES BY FILE-ID. The VMS utility routines
manual incorrectly documents that the writer of the input routine may
choose to open a file by either file-id or file name. The writer may
indeed choose to open by file name, but in so doing, he breaches the
security of the system:
3. The third conclusion is obvious: CMU is using the file name to open
the file, and hence breaches the security of your system:
If you don't believe me that your symbiont is insecure, find a directory
from which your symbiont correctly. Create a command procedure which does
something like the following:
$ create x.x;1 sys$input
$ print/delete/q=<CMU queuename>/char=128 x.x;1
$ delete x.x;1
$ set file/enter=x.x;1 <name of file user shouldn't be able to read or delete>
Then run this from a totally non-privileged user's account.
Then from the same account, noting which job was queued by the procedure,
use
$ set que/entry=nnn/nochar <CMU queue>
to release the job.
I am just writing this off the top of my head. If it doesn't work as given,
something similar will work and will print (or do whatever "CMU" does) AND
delete a file which the user shouldn't be able to touch.
The writer of a VMS symbiont, if he gets into torture, could theoretically
open the file by name and then check to make sure the ID fields in the NAM
block match those of the file just opened, but this is obtuse, and unnecessary,
and 10 to 1 the writer of your symbiont didn't--There is no reason to do
this.
In short, the writer of software which runs with system privilege (such
as your symbiont) should be responsible for privilege questions, although
DEC should have been more responsible for their documentation. I've reported
the documentation problem to DEC (1-800-etc.) and they verified that it
is misdocumented, but I haven't seen new documentation fix it. I would
talk gently to CMU (assuming the above test works) and suggest a change
in their input routine.
Ray Whitmer
AMMON: w