Article 4656 of vmsnet.internals: In article <4nhv58$u84@nntpd.lkg.dec.com>, everhart@star.enet.dec.com (Glenn C. Everhart) writes: > > Yo...I made no claims about the security of exec names etc...that wasn't > part of the question. Also the question made (as I recall...could be > wrong) no mention of open. If the logicals are translated in exec mode > and defined with no-alias however, lower mode logicals are prevented from > being created. Note that the following something of a nit-pick. It is certainly true that no-alias logical name creation in conjunction with exec mode translation can secure an application. I simply object to the emphasis on the no-alias side. I claim that it's (usually) far easier to prevent an application from seeing offensive logical names than to prevent those names from being created in the first place. If you define with no-alias, your defense against the creation of outer mode logical names is limited -- it's confined to the single table within which the inner mode name is defined. $ DEFINE /JOB /EXEC /NAME=NO_ALIAS A B $ DEFINE /JOB A C %SYSTEM-F-DUPLNAME (So far, so good) $ DEFINE A C $ WRITE SYS$OUTPUT F$TRNLNM ( "A" ) C (Ooops) Obviously, this is "cheating". I'm defining a no-alias logical name in one table and translating it from another. Crackers cheat. While it is possible to secure an application using no-alias logical names, one must take care. (Are you specifying a single name table to translate from? Did you secure that name table name in LNM$PROCESS_DIRECTORY? In LNM$SYSTEM_DIRECTORY? Did you check LNM$DIRECTORIES to make sure there aren't any other directories at this site? Were those directories secure both when you defined the name and when you translated it? You didn't define using a lower-case name, did you?) If logicals are translated in exec mode, outer mode logicals are not seen. This guarantee is tougher to cheat on. John Briggs briggs@vitro.com