Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!rutgers!ucla-cs!zen!ucbvax!GRIN2.BITNET!MCGUIRE From: MCGUIRE@GRIN2.BITNET Newsgroups: comp.os.vms Subject: RE: privs in spawn processes Message-ID: <8707282010.AA02689@ucbvax.Berkeley.EDU> Date: Mon, 27-Jul-87 14:33:00 EDT Article-I.D.: ucbvax.8707282010.AA02689 Posted: Mon Jul 27 14:33:00 1987 Date-Received: Thu, 30-Jul-87 01:51:17 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 50 > Date: Sun, 26 Jul 87 21:14 EST > From: ANIL KHULLAR> 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