Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!zen!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA Newsgroups: comp.os.vms Subject: RE: privs in spawn processes Message-ID: <8707300922.AA12007@ucbvax.Berkeley.EDU> Date: Thu, 30-Jul-87 05:22:16 EDT Article-I.D.: ucbvax.8707300922.AA12007 Posted: Thu Jul 30 05:22:16 1987 Date-Received: Sat, 1-Aug-87 07:00:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 44 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 -------