Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

Why is /EXEC not needed for AUTHORIZE?

 
SOLVED
Go to solution
Highlighted
Advisor

Why is /EXEC not needed for AUTHORIZE?

As you can see below, AUTHORIZE doesn't need SYSUAF to be defined with /EXEC. Why? And can someone please post an example in which it is? Thanks!

$ INSTALL LIST AUTHORIZE

DISK$OPENVMS062:.EXE
AUTHORIZE;1 Prv
$ SHOW DEFAULT
BLAH:[SYS0]
$ SHOW LOG/FULL SYSUAF
%SHOW-S-NOTRAN, no translation for logical name SYSUAF
$ MCR AUTHORIZE
%UAF-E-NAOFIL, unable to open system authorization file (SYSUAF.DAT)
-RMS-E-FNF, file not found
Do you want to create a new file? N
$ DEFINE/SYSTEM SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ MCR AUTHORIZE
UAF> Exit
%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy database
%UAF-I-RDBNOMODS, no modifications made to rights database
$ SHOW LOG/FULL SYSUAF
"SYSUAF" [super] = "SYS$SYSTEM:SYSUAF.DAT" (LNM$SYSTEM_TABLE)
$

AEF
12 REPLIES 12
Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

AEF,

for local access to SYSUAF, you can even define your own process logical name.

But LOGINOUT will NOT honour a system-wide SYSUAF logical name in SUPERVISOR mode.

SYS$MANAGER:SYLOGICALS.TEMPLATE explicitly suggests:

$ DEFINE/SYSTEM/EXEC SYSUAF ...

Volker.
Highlighted
Valued Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

As to why? I vaguely recall that it was done to allow you to make massive changes to a copy of SYSUAF using AUTHORIZE, then copy the updated SYSUAF into place monolithically.

I also vaguely recall that there are cases of satellite cluster members where the users are restricted to their own little satellite but the cluster manager can control their local SYSUAF from a single spot. But again, haven't played with that in ages.

As to posting an example, why bother? It just looks like:

$ DEFINE /SYSTEM/EXEC SYSUAF SYS$SYSTEM:SYSUAF.DAT
$ SHOW LOGICAL/FULL SYSUAF
"SYSUAF" [exec] = "SYS$COMMON:[SYSEXE]SYSUAF.DAT" (LNM$SYSTEM_TABLE)

What's to see?
Sr. Systems Janitor
Highlighted
Advisor

Re: Why is /EXEC not needed for AUTHORIZE?

But the DCL dictionary under DEFINE says this:

Executive Mode

In looking up logical names, all privileged images and utilities such as LOGINOUT bypass the user mode and supervisor mode names and tables. If a logical name is to be used by a privileged image, including a utility, it must be defined in executive or kernel mode in an executive or kernel mode table. Other candidates for logical names defined in executive mode are the names of public directories used by your work group and system resources, such as print queues and system disks.

AUTHORIZE is a privileged image, so according to the above it should ignore supervisor and user logical names, but it doesn't. Apparently, what it says is wrong. It should instead say that SOME privileged programs under SOME contexts require Exeucitve or Kernel mode logical names.

Can you or someone provide a less "dangerous" example?

Thanks.

AEF
Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

Richard,


to make massive changes to a copy of SYSUAF using AUTHORIZE


If one plans to do that, one also has to be careful about RIGHTSLIST. You need to define a separate process /EXEC mode logical to a local copy of RIGHTSLIST.DAT, if you plan to make changes in the 'local' SYSUAF, which also affect RIGHTSLIST.

Volker.
Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

AEF,

AUTHORIZE just seems to be installed with AUDIT privileges.

LOGINOUT - on the other hand - is installed with CMKRNL. So if it would try to access SYSUAF from kernel mode, it won't see 'outer mode' logical names.

Volker.

Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

AEF,

I assume you are the same AEF that frequent C.O.V. right?
A quick google for AEF + OpenVMS show a good few hits, but no name/affiliation in recent posts.
Come'on, let's hear it.
Stand up and be counted!

Anyway...

Yes, that link just mentioned has an appropriate, and still equally valid and applicable prior discussion.

Why do you feel it needs to be an EXEC logical?
How would that help?
Security/Protection still comes from basic file object protection right no matter what flavor of logical?

SYSUAF is just an RMS indexed file, which you can manipulate with DCL, Datatrieve, any program you choose to write, or indeed the provided AUTHORIZE executable which can be handy as it understands SYSUAF very well.


Best regards,
Hein van den Heuvel




Highlighted
Honored Contributor
Solution

Re: Why is /EXEC not needed for AUTHORIZE?

AEF,

Just to make things clear... we need to realise the difference between:

1) The system accessing and using SYSUAF to authenticate users logging in - this requires a trusted logical name, EXEC mode, in a table in the EXEC mode translation of LNM$FILE_DEV

2) A utility to edit a SYSUAF file. This is just a read/modify/write editor application operating on a data file.

AUTHORIZE is an ancient program, dating back to VMS V1. The UAF part accesses the file directly and has no idea the file is anything special. If it were written more recently it would use the $SETUAI/$GETUAI interface instead of the raw bits, and would therefore be subject to security access rules, and be independent of the physical record layout. The reason AUTHORIZE is privileged is the RIGHTSLIST and proxy database access is done (correctly!) via privileged system service interfaces.

So, the behaviour you observe is an inconsistency. Just an accident of history.

I believe AUTHORIZE should have been rewritten back when RIGHTSLIST was introduced - it would have fixed quite a few things. For example, the "Do you want to create a new file?" question is just plain silly and should have been removed years ago. It makes very little sense and causes WAY more harm than good. Unsuspecting system managers accidently create UAFs in incorrect places and work on them without realising they're not operating on the "real" SYSUAF. Another case of OpenVMS fanatacism about upwards compatibility taken to illogical extremes.
A crucible of informative mistakes
Highlighted
Honored Contributor

Re: Why is /EXEC not needed for AUTHORIZE?

>>John:
I believe AUTHORIZE should have been rewritten back when RIGHTSLIST was introduced - it would have fixed quite a few things. <<

And even more needed is (would have been) a $uaf_scan system service to set wildcard context for the $getuai/$setuai system services in a similar way $process_scan provides it for $getjpi.
Then all the many programs now directly accessing sysuaf or uaf listings could be written in a consistent and supported manner.
http://www.mpp.mpg.de/~huber