jeh@crash.cts.com (Jamie Hanrahan) (01/09/88)
This followup is inspired by the following commentary re. BACKUP and PHY_IO, but it seemed to be general-enough information to be worth changing the subject line... In article <880106185356.00b@CitHex.Caltech.Edu> carl@CITHEX.CALTECH.EDU (Carl J Lydick) writes: > > > b) install BACKUP with this privilege (PHY_IO) > > > > We decided to use solution b) ! > > Unfortunately then BACKUP also refuses to work (even when all privileges are > > turned on, like the following command for our daily backup operations): > > > > $ BACKUP /IGNOR=INTERL /REWIND /FAST /RECORD /DENS=6250- > > /JOU=THD$OPER1:[BACKUP]BACKUP14.BJL.1 - > > USER02:[*...] /SINCE=BACKUP MUA0:6JANBAK.BCK > > %DCL-W-ACTIMAGE, error activating image ENCRYPSHR > > -CLI-E-IMGNAME, image file DUA0:[SYS0.][SYSLIB]ENCRYPSHR.EXE;3 > > -SYSTEM-F-PRIVINSTALL, shareable images must be installed to run privileged > > image > > > > Image SYS$LIBRARY:ENCRYPSHR.EXE must also be installed with that privilege! > > > >I could be wrong, but I don't think you have to INSTALL ENCRYPSHR.EXE with >privileges; merely INSTALLing it /OPEN/HEADER/SHAR should suffice (I base this >claim on the fact that MAIL, which is installed with SYSPRV, can call TPU, and >TPUSHR.EXE is installed with no privs). In fact, you can't INSTALL a shareable image with privileges, at least not in the sense of ADD shareable_image/PRIV=(...). A lot of folks have *wanted* to do that, so that whenever a procedure in the shareable image was called the process would get the associated privs, which would disappear when the routine RET'd, but that capability does not exist. Nor is it likely to, ever, since the CALL/RET mechanism does not allow for saving and restoring of privs. What you *can* do, if you want this effect, is to write a privileged shareable image -- otherwise known as a user-written system service. This must be linked with the /PROTECT and /SHAREABLE options and INSTALLed with the /PROTECT and /SHARED qualifiers. Such an image provides one or more entry points followed by CHMK #change_mode_code instructions, kernel and executive dispat- chers (CASE instructions) that relate the change_mode_codes to the routine to be executed for each, and the routines themselves. Since the routines run in kernel mode they can do anything you want, including twiddling the privilege masks. When an executable image that's been linked with one of these beasts is activated, the entry vectors and change mode dispatchers are placed in pages that can't be written in user mode, so that the user can't decide to replace the privileged code. A template appears in SYS$EXAMPLES:USSDISP.MAR, and the mechanism is described in the Internals manual (of course). It would be quite simple to write something that stayed in kernel mode just long enough to turn on the privs you wanted, got back to user mode, did whatever you wanted to do in user mode, then CHMK'd to another routine that restored the original privs. Have fun...
carl@CITHEX.CALTECH.EDU (Carl J Lydick) (01/10/88)
> In fact, you can't INSTALL a shareable image with privileges, at least not > in the sense of ADD shareable_image/PRIV=(...). A lot of folks have *wanted* > to do that, so that whenever a procedure in the shareable image was called the > process would get the associated privs, which would disappear when the routine > RET'd, but that capability does not exist. Nor is it likely to, ever, since > the CALL/RET mechanism does not allow for saving and restoring of privs. No, you're wrong. You CAN install a sharable image with privs. For example, the commands: $ INSTALL:==$INSTALL/COMMAND $ INSTALL ADD SYS$SHARE:ENCRYPSHR/PRIV=PHY_IO works just fine. The image SYS$SHARE:ENCRYPSHR.EXE is (after these two commands), in fact, installed with PHY_IO priv. What you were trying to say is that unless the image SYS$SHARE:ENCRYPSHR.EXE is activated from the level of the command-language interpreter (typically DCL), the privs with which it is installed don't get applied.
jeh@crash.cts.com (Jamie Hanrahan) (01/12/88)
In article <880110023401.03e@CitHex.Caltech.Edu> carl@CITHEX.CALTECH.EDU (Carl J Lydick) writes: > > > In fact, you can't INSTALL a shareable image with privileges, at least not > > in the sense of ADD shareable_image/PRIV=(...). A lot of folks have *wanted* > > to do that, so that whenever a procedure in the shareable image was called the > > process would get the associated privs, which would disappear when the routine > > RET'd, but that capability does not exist. Nor is it likely to, ever, since > > the CALL/RET mechanism does not allow for saving and restoring of privs. > >No, you're wrong. You CAN install a sharable image with privs. For example, >the commands: > $ INSTALL:==$INSTALL/COMMAND > $ INSTALL ADD SYS$SHARE:ENCRYPSHR/PRIV=PHY_IO >works just fine. The image SYS$SHARE:ENCRYPSHR.EXE is (after these two >commands), in fact, installed with PHY_IO priv. What you were trying to >say is that unless the image SYS$SHARE:ENCRYPSHR.EXE is activated from the >level of the command-language interpreter (typically DCL), the privs with >which it is installed don't get applied. No, what I should have said is that it is *not meaningful* to use the /PRIV qualifier when installing shareable images -- Knowing this, I never bothered to try it, so I didn't know that INSTALL would accept it. But the fact that INSTALL does not check the image type, shareable vs. executable, to decide whether the /PRIV qualifier will be accepted does not mean that it makes any sense to include /PRIV when installing a shareable image. In the example you provide, the PROCPRIV quadword in the Known File Entry built by INSTALL may indeed have the PHY_IO bit set, but who cares? The image activator ignores KFE$Q_PROCPRIV when mapping a shareable image. Is the image installed with privileges or not? According to the data structures, yes, but according to the effect you get when the image is activated, no, it isn't. Nor is it meaningful to try to activate a shareable image, installed or other- wise, as if it were an executable (i.e. via the RUN command or by specifying it as the `image' argument for a $CREPRC call). All you'll get is a curt "No transfer address" message.