Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!sdcsvax!ucsdhub!jack!crash!jeh
From: jeh@crash.cts.com (Jamie Hanrahan)
Newsgroups: comp.os.vms
Subject: Re: INSTALLing shareable images with privs
Message-ID: <2334@crash.cts.com>
Date: 11 Jan 88 22:08:09 GMT
References: <2312@crash.cts.com> <880110023401.03e@CitHex.Caltech.Edu>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Organization: CMKRNL Press, San Diego, CA
Lines: 37
Summary: No, YOU'RE wrong.

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.