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