MCGUIRE@GRIN2.BITNET (07/27/87)
> Date: Sun, 26 Jul 87 21:14 EST > From: ANIL KHULLAR <ANK%CUNYVMS1.BITNET@wiscvm.wisc.edu> > Subject: Privs in spawn process > > I have noticed that some users who have been given extra priveleges like > PHY_IO, LOG_IO, and SHARE cannot set their privs in a spawned process, unless > they are DEFAULT PRIVS as well. > > However when I spawn out of GNUEmacs, {C-x, C-z} I can set mine if the top > process had SETPRV too. Is there a way that the privs for others are mapped > into their sub-process without changing their privs to DEFAULT ? Background: A process has four sets of privileges. One, AUTHPRIV, defines which privileges the process is authorized to enable. Another, CURPRIV, defines which privileges the process has right now. The problem you are experiencing may be a result of the following two oddities about privileges. 1. SETPRV, the privilege which lets you turn on any other privilege, does not have to be `current' to use. VMS will also look in your authorized privileges to see if you could turn on SETPRV, just to save you the trouble. In sum, you don't have to turn on SETPRV before you can turn on other privileges. 2. When you spawn, your current privileges are copied to _both_ the authorized privileges _and_ current privileges of the subprocess. That is, AUTHPRIV_1, CURPRIV_1 <- CURPRIV_0 The implication is that the subprocess can only turn on privileges which were _current_ in the parent process. If you are in the habit of turning off your privs with a command such as SET PROC/PRIV=(NOALL,TMPM,NETM), you may later spawn a subprocess which is neither authorized SETPRV nor currently granted SETPRV. That subprocess cannot, therefore, enable any other privileges. (For completeness, the other two privilege masks are IMAGPRIV, defining which privileges the current image was INSTALLed with, and PROCPRIV, defining which privileges the process had before invoking a privileged image, so that CURPRIV can be reset during image rundown.) I don't like the behavior of VMS under number 2. In fact, VMS V3 didn't behave this way at all. Does anybody have any idea why SPAWN doesn't copy AUTHPRIV to AUTHPRIV and CURPRIV to CURPRIV anymore? This was brought up at a DECUS advanced Q&A session some time back, and there was some muttering about a security problem, but no clear answer. Ed McGuire Systems Coordinator Grinnell College MCGUIRE@GRIN2.BITNET
LEICHTER-JERRY@YALE.ARPA (07/30/87)
Mr. McGuire provides an excellent discussion of process privileges and SPAWN,
and then comments:
I don't like the behavior of VMS under number 2 [SPAWN copies the current
privileges - CURPRIV - to both the current and authorized - AUTHPRIV
privileges of the created subprocess]. In fact, VMS V3 didn't behave this
way at all. Does anybody have any idea why SPAWN doesn't copy AUTHPRIV to
AUTHPRIV and CURPRIV to CURPRIV anymore? This was brought up at a DECUS
advanced Q&A session some time back, and there was some muttering about a
security problem, but no clear answer.
Since SPAWN was introduced in VMS V4, it can hardly have changed its actions
from V3! However, it inherits the action of the underlying $CREPRC system
service, which has always copied CURPRIV to all three of AUTHPRIV, PROCPRIV,
and CURPRIV. This effect used to be a lot less noticable for three reasons:
o SPAWN is a lot more convenient than $CREPRC for use in typical
programs, especially to allow spawning interactive processes.
Few run-of-the-mill programs used $CREPRC.
o $CREPRC allows you to specify exactly the privileges you want the
new process to have.
o It wasn't until V4 that AUTHORIZE maintained a distinction between
authorized privileges (/PRIV) and privileges actually turned
on at LOGIN (/DEFPRIV), so that except when running programs
installed with privileges, V3 processes would almost always
have the same value in CURPRIV and AUTHPRIV anyway.
$CREPRC doesn't provide any way to specify the privilege masks individually.
Also, $SETPRV can only set CURPRIV and PROCPRIV - it can't set AUTHPRIV.
It's common practice for privileged images to manipulate CURPRIV so that,
for example, MAIL, even though it's installed with SYSPRV, can avoid using
it when the user tries to read a mail file. Copying the privileges as is
currently done allows the same logic to apply to SPAWNed subprocesses. It
also means that one can create CAPTIVE accounts with privileges, and still
allow a program running under such an account to SPAWN a subprocess safely -
just be sure that any priv's you don't want to pass on are turned off in
CURPRIV before you do the SPAWN.
All in all, this definition is one of those compromises.
-- Jerry
-------LEICHTER-JERRY@YALE.ARPA (08/05/87)
> From: LEICHTER-JERRY@YALE.ARPA > Since SPAWN was introduced in VMS V4, it can hardly have changed its > actions from V3! Hmmm. Then I really have to wonder what the command called SPAWN that I used under VMS V3 was. A fantasy? How about "an error"? -- Jerry The red-faced VMS non-historian (Gee, I don't remember THAT from V2.1...) -------