Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!ucbvax!info-vax From: info-vax@ucbvax.ARPA Newsgroups: fa.info-vax Subject: Re: privileges and spawning.... Message-ID: <6108@ucbvax.ARPA> Date: Tue, 9-Apr-85 04:46:57 EST Article-I.D.: ucbvax.6108 Posted: Tue Apr 9 04:46:57 1985 Date-Received: Wed, 10-Apr-85 03:15:09 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 57 From: engvax!KVC@cit-vax Does anyone out there know how the hell SPAWN decides exactly which privileges the child process is going to inherit from the parent????????????????????????? As far as I can tell (from reading the ufiche), SPAWN does not specify anything in the PRVADR argument to $CREPRC when it creates the process. This means that $CREPRC should use it's default, right? Well, since the manual was useless in this regard, I looked at the code for SYS$CREPRC. As far as I can tell, it gets the privilege mask to build into the created process from the callers privileges in the first quadword of the caller's PHD (PHD$Q_PRVMSK). This, however, does not seem to be what's really happening. I have to be able to run MAIL with SYSPRV and DETACH, so I can specify my own, foreign, MAIL protocol. In order to do this, I created a program which does nothing but SPAWN the magic MAIL/PROTOCOL= command. Now, if I run the program from a privileged account with SYSPRV and DETACH enabled, it works just fine. If, however, I install the image with SYSPRV and DETACH, and run it from an account without SYSPRV and DETACH, nothing happens. This indicates that the image privs are not masked into the PHD priv word, as I thought they were. So, to get around this I put in a call to SYS$SETPRV. Looking at the code to SETPRV, I see that it definitely puts the privs you ask into the PHD priv mask (in addition to the PCB priv mask) and that the IMAGE privs are most definitely included in the mask of privs that you are allowed to enable. This, however, doesn't work either. Finally, in desparation, I tried using the PRMFLG in $SETPRV. AH HAH! success!! Now the privs are copied to the subprocess. Only problem is that PRMFLG does not allow the image privs to be included in the mask of privs that you can enable. This is to prevent installed programs from accidently leaving you with permanent privs. So, we have a catch-22 with $SETPRV. Only permanent privs get copied to the subprocess, but an installed image cannot affect (and rightly so) the privs it's installed with in a permanent fashion. By the way, SETPRV privilege means nothing to the $SETPRV service unless it's in the authorized priv mask. Now, the only difference between setting permanent and temporary privs in the SYS$SETPRV code is that it sets them in CTL$GQ_PROCPRIV in addition to setting them in the PCB and PHD. Yet, SYS$CREPRC does not even reference the symbol CTL$GQ_PROCPRIV!!!! How is it that that affected my SPAWN? Does DCL reset privileges to the CTL mask whenever you do a CLI callback? Any one have any suggestions on how I (safely) allow a non-prived account to SPAWN a process with privileges for just one function? (The non-prived account cannot be used by anyone anyway, so I'm not THAT worried about someone breaking in through it if it only has privs while MAILing. I am too paranoid to authorize it for SYSPRV all the time!). I realize that DEC is making this hard to do because it can be a security hole, on the other hand requiring SYSPRV and DETACH to talk to MAIL with your own protocol makes this necessary. I definitely do NOT want my network account to have SYSPRV and DETACH as authorized privileges, since it (UUCP) isn't real safe. Of course, this wouldn't be a problem if MAIL just checked to see if I had a certain identifier and then I could grant that identifier to the UUCP account, but it seems no one uses identifiers like they should... Oh well... /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.