[comp.os.vms] Callable EDT and privs

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