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