Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ucbvax!drcvax.arpa!graham
From: graham@drcvax.arpa.UUCP
Newsgroups: comp.os.vms
Subject: Callable EDT and privs
Message-ID: <8712041340.AA14659@ucbvax.Berkeley.EDU>
Date: Fri, 4-Dec-87 07:05:00 EST
Article-I.D.: ucbvax.8712041340.AA14659
Posted: Fri Dec  4 07:05:00 1987
Date-Received: Tue, 8-Dec-87 02:05:14 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: 
Distribution: world
Organization: The ARPA Internet
Lines: 29

>For instance, if you're writing a mailer 
>that needs to access files via BYPASS privilege, you turn on BYPASS only
>when accessing those files (SYSUAF, users' mail files, etc.), and turn it
>off again as soon as the file is open.  You don't leave it on, for instance,
>during the `prepared file to include?' sequence...  Also, be careful about
>logical name translations -- a program accessing files via enhanced privs
>should only use `trusted' logical names (system name table, exec mode,
>etc.).  With these caveats, one can write enhanced-priv programs and still
>safely use things like callable EDT.

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

I can't figure out how to call EDT and turn off the privs after the file
has been opened because that operation is transparent to the program. 

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.

Any more thoughts?

Dan Graham
graham@drcvax.arpa
------