Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!umn-d-ub!rutgers!ucsd!ucbvax!VENUS.YCC.YALE.EDU!LEICHTER
From: LEICHTER@VENUS.YCC.YALE.EDU ("Jerry Leichter ", LEICHTER-JERRY@CS.YALE.EDU)
Newsgroups: comp.os.vms
Subject: re: Undocumented priv bits...
Message-ID: <8808040647.AA16046@ucbvax.berkeley.edu>
Date: 16 Jul 88 20:12:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 32


	***> From: "IVAX::IJAH400" <ijah400%ivax.decnet@gold.bacs.indiana.edu>
	***> 
	***> UPGRADE and DOWNGRADE are both listed in STARLET.REQ, they are
	***> bits 0 and 1 in the second privilege longword....

	The DCL command SHOW PROC/PRIV won't let you see them (Although I
	think it used to) but the DCL Lexical F$GETJPI() will.

	...But what are they used for?  Perhaps the VMS "Secure System"
	package?  or whatever it's called ?

Good guess.  Yes, they are used in that package (I think it's called SE/VMS);
they are part of a non-discretionary access control system.  (This is the
idea in the government's "unclassified", "sensitive", "secret", "top secret"
scheme.  If you log in to an "unclassified" account, you can't see anything
from a higher level.  If you log into a, say, "secret" account, you can see
"secret" stuff, but you can't move it into an "unclassified" directory.
UPGRADE and DOWNGRADE are rights needed to modify security levels - e.g., to
take something "secret" and make it "unclassified", you need DOWNGRADE.
There's a lot more to it, but it's not worth going into here.)

Nothing in "normal" VMS makes use of the bits for anything, except that for
simplicity the trivial routines that examine and display them are part of
VMS.  Otherwise, SE/VMS would have that much more to patch.

Someone also asked about TMPJNL and PRMJNL.  They are part of another VMS
optional facility, RMS journaling.  Again, they don't do anything but get set
and displayed.  (Actually, I'm not sure if RMS journaling as it actually got
implemented actually uses these bits - they may just be holdovers from an
early design.)
							-- Jerry