Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!uw-beaver!cornell!rochester!bbn!uwmcsd1!marque!gryphon!crash!jeh
From: jeh@crash.cts.com (Jamie Hanrahan)
Newsgroups: comp.os.vms
Subject: INSTALLing shareable images with privs
Summary: Not exactly.
Keywords: install shareable image privilege
Message-ID: <2312@crash.cts.com>
Date: 9 Jan 88 01:42:28 GMT
References: <880106185356.00b@CitHex.Caltech.Edu>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Organization: CMKRNL Press, San Diego, CA
Lines: 52

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...