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