Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!hao!ames!sdcsvax!ucsdhub!jack!crash!jeh
From: jeh@crash.cts.com (Jamie Hanrahan)
Newsgroups: comp.os.vms
Subject: Re: Callable EDT and privs
Message-ID: <2086@crash.cts.com>
Date: Sat, 5-Dec-87 07:14:24 EST
Article-I.D.: crash.2086
Posted: Sat Dec  5 07:14:24 1987
Date-Received: Thu, 10-Dec-87 06:19:54 EST
References: <8712041340.AA14659@ucbvax.Berkeley.EDU>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Organization: Simpact Associates, San Diego, CA
Lines: 23
Summary: Clarification re use of enhanced privs

In article <8712041340.AA14659@ucbvax.Berkeley.EDU>  writes:
>This [turning enhanced privs off except when needed] is good advice.
>One thing though, how can I write a privileged 
>installed program to access callable EDT and not have the privs turned on 
>when the call to EDT is made.  If the person running the program needs 
>access to a file he could not normally access, the program will have to 
>turn on the privs just before issuing the call to EDT.  This defeats any 
>security checks made, it seems to me.  

Oh.  I assumed that the program needed to access a normally-inaccessible
file, then call EDT to let the user work on something else -- not that 
EDT itself would need to access the forbidden file.  Hmmm.  I suppose you
could have the program turn the privs on, copy the file (accessed through
trusted logical names and etc.) to a temporary, turn the privs off, then
call EDT to edit the temporary.  Ugh, but it closes the hole.  

>It occurs to me that using the $CREPRC service would be faster than
>LIB$SPAWN, but it still creates another process with the inherent overhead 
>of that.

Yes, $CREPRC is considerably faster than LIB$SPAWN.  The difference is easily
2:1 since the $CREPRC'd process doesn't need to activate the CLI image, let
alone copy all the process logicals, DCL symbols, etc., etc.