graham@drcvax.arpa.UUCP (12/04/87)
>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 ------
mike@VAX.OIT.UDEL.EDU ("Michael J. Porter") (12/04/87)
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. /// Write a "FILEIO" routine that turns on privs, and opens the file, and then turns off privs - or open the file in advance of the EDT$EDIT call and ignore the EDT$K_OPEN_INPUT code. "FILEIO" is a routine address passed to "EDT$EDIT". mike@vax.oit.udel.edu ------
jeh@crash.cts.com (Jamie Hanrahan) (12/05/87)
In article <8712041340.AA14659@ucbvax.Berkeley.EDU> <graham@drcvax.arpa> 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.
jimp@cognos.uucp (Jim Patterson) (12/10/87)
In article <8712041340.AA14659@ucbvax.Berkeley.EDU> <graham@drcvax.arpa> writes: > 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. If you want the user to be able to edit a normally protected file, one way to go is to use the EDT file input/output hooks. These are provided to the EDT interface as procedure parameters. If passed, EDT will call these routines to handle file i/o to specific files. See the callable EDT description for full information. It's in the standard DOC set somewhere, but I don't remember just where. Your file i/o routines can enable privileges, open the files needed, and then disable privileges before returning to EDT. Once the file is opened, there's no need to turn privileges on anymore. Since there's no way that your user can enable privileges from within EDT, it remains secure. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4