Behaviour of F$TRNLNM

[Bart Zorn_1]

Hello,

It appears that F$TRNLNM("",,,"EXECUTIVE") always returns a null string.

Reason for this is that the second argument defaults to LNM$DCL_LOGICAL, which is defined (only) in SUPERVISOR mode in LNM$SYSTEM_DIRECTORY.

LNM$DCL_LOGICAL translates to LNM$FILE_DEV, which has both a SUPERVISOR and an EXECUTIVE mode version in LNM$SYSTEM_DIRECTORY.

If an EXECUTIVE mode version of LNM$DCL_LOGICAL is added (either to LNM$SYSTEM_DIRECTORY or LNM$PROCESS_DIRECTORY), F$TRNLNM behaves in a more natural manner; it will translate EXECUTIVE mode logical names normally.

Of course, I can add this second definition of LNM$DCL_LOGICAL at system startup, but I wonder: is there a compelling reason why it exists only in SUPERVISOR mode?

Any thoughts?

Regards,

Bart Zorn

[Ian Miller.]

I guess its because DCL runs in supervisor mode.

[Bart Zorn_1]

Ian,

Although true, that is not the reason why LNM$DCL_LOGICAL is defined in SUPERVISOR mode.

In SYS$STARTUP:VMS$INITIAL-050_VMS.COM LNM$DCL_LOGICAL is defined with an explicit /SUPER qualifier.

I could just as easily have been /EXEC !

Bart

[Bart Zorn_1]

Hmm... of course I meant:

It could just as easily have been /EXEC !

Bart

(I don't think I want to be /EXEC)

[Wim Van den Wyngaert]

You specified 4 "," before executive.
Then it's not the translation but the item to report.
When "executive" is after 2 "," it works fine.

Wim

[Wim Van den Wyngaert]

Haast en spoed is zelden goed.

The word executive after 2 "," should indicate the index. "executive" is accepted but not used (???). So it does return exec logicals.

It's after 3 "," that you have the mode. And yes, it doesn't work.

Wim

[Wim Van den Wyngaert]

It does work when the table is specified. May be the intention is that you MUST specify a table when using exec logicals.

Fwiw

Wim

[Jess Goodman]

Many years ago I did your suggested work-around and have not had any problems due to it. In my SYSTARTUP_VMS.COM I have:

$DEFINE/NOLOG/TABLE=LNM$SYSTEM_DIRECTORY/EXEC -
LNM$FILE_DEV - LNM$PROCESS,LNM$JOB,LNM$GROUP,LNM$SYSTEM,DECW$LOGICAL_NAMES

[John Gillings]

re: Jess

(defining LNM$FILE_DEV in EXEC mode)

I'm not sure if that's a good idea... Note that by default, OpenVMS already defines both SUPER and EXEC mode translations for LNM$FILE_DEV:

$ show log/full/table=lnm$system_directory lnm$file_dev*

(LNM$SYSTEM_DIRECTORY) [kernel] [shareable,directory]
[Protection=(RWC,RWC,R,R)] [Owner=[SYSTEM]]

"LNM$FILE_DEV" [super] = "LNM$PROCESS"
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"
= "DECW$LOGICAL_NAMES"
"LNM$FILE_DEV" [exec] = "LNM$PROCESS"
= "LNM$JOB"
= "LNM$GROUP"
= "LNM$SYSTEM"


The reason is the EXEC mode translation is used for "trusted" logical name translation. The above is V7.3-2, in (much?) older versions, the exec mode translation only contained LNM$SYSTEM. It was relaxed to make it possible to have duplicate file names for installed images (circa V6, at the same time global section names got "mangled").

Although defining the logical name is most unlikely to break anything, it does allow a wider scope for trusted logical name translation, and thus potentially more tables that you implicitly trust. In the above case, the only difference is the DECW$ logical name table, which is *probably* trustworthy. Just be very careful about including any other logical name tables that might be writeable from non-trustworthy processes.

Re: Bart,

I think there's a bug here. F$TRNLNM is just a jacket for SYS$TRNLNM. If you call $TRNLNM from a non-privileged process you can correctly translate logical names by mode (I've tried it for user, super and exec, but not kernel since there's no simple way to create them!)

Please log a case with HP customer services to get it fixed!

Let me know if you want a simple test program.

[John Gillings]

Oops, sorry, I'll take that back...

$TRNLNM requires a table name. F$TRNLNM does not - it defaults to LNM$DCL_LOGICAL. Calling the system service with LNM$DCL_LOGICAL does not find exec mode logical names in the search path:

%SYSTEM-F-NOLOGNAM, no logical name match

The SSRM doesn't say that the table name logical name is required to be at least at MODE, but I guess it makes a kind of sense.

Simple workaround:

F$TRNLNM("","LNM$FILE_DEV",,"EXECUTIVE")

[Hoff]

This behavior looks to be a variation of the typical privileged image activation. Privileged images will deliberately skip the translations from the outer modes, and will ignore even privileged definitions in unprivileged tables.

The table and the logical name must all be in the requested mode, or in a more privileged mode. If you try to aim the translation elsewhere from a less-privileged mode and/or a definition in a less-privileged table, it will be ignored.

[Bart Zorn_1]

Thanks for all your reactions.

However, In my initial post I already stated what the real problem was, and nobody answered my question: why isn't there an EXEC mode definition of LNM$DCL_LOGICAL in the first place?

Bart

[John Gillings · Accepted solution]

Bart,

>why isn't there an EXEC mode definition of
>LNM$DCL_LOGICAL in the first place?

Because it wasn't needed. The only reason for defining EXEC mode logical names is to provide a distinction between privileged and non-privileged access. The EXEC mode definition can be limited to a trusted search path, and prevents non-privileged definitions from hijacking translations to (potentially) introduce trojan horses. By not defining an EXEC mode translation at all, the logical name is eliminated as a potential security hole.

LNM$DCL_LOGICAL is a bit of an oddity and rather obscure. It isn't used in many places. Before VMS V4, there were only 3 hardcoded logical name tables PROCESS, GROUP and SYSTEM. When the logical name architecture was radically changed in V4 to include multiple tables, a mechanism was required to provide compatibility with the older architecture and the $TRNLOG system service (and now obselete and undocumented lexical function F$TRNLOG). See entries in LNM$SYSTEM_DIRECTORY for LOG$* and TRNLOG$* - these replicate the seven old search paths within the new mechanism. LNM$DCL_LOGICAL was originally the default compatibility search path LOG$PROCESS, LOG$GROUP, LOG$SYSTEM, but over time it's been changed to be LNM$FILE_DEV, and therefore redundant.

On potential solution to your issue would be to change F$TRNLNM to default the table name to LNM$FILE_DEV (which does have an EXEC mode translation). I'd guess the reason that hasn't happened is no one has asked, so there's no incentive to invest the resources required to change the code and documentation. If you feel strongly about it, log a case.

In the mean time, it should be safe for you to define an EXEC mode translation for LNM$DCL_LOGICAL (I'd suggest pointing it at LNM$FILE_DEV), however, this makes any code you write using F$TRNLNM and EXEC mode dependent on your non-standard environment. On the other hand, if you simply add the table name LNM$FILE_DEV to your call, it will work on all standard OpenVMS environments, and will continue to work even if F$TRNLNM is changed in the future.

[Bart Zorn_1]

Thanks, John.

I think that specifying LNM$FILE_DEV in the call is the best solution.

However, changing the explicit /super into /exec in SYS$STARTUP:VMS$INITIAL-050_VMS.COM in a future update of OpenVMS will not break anything, and I do not see how it could add a security risk.

Regards,

Bart