Why is /EXEC not needed for AUTHORIZE?

[AEFAEF]

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

[Volker Halle]

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.

[Richard W Hunt]

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?

[AEFAEF]

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

[Volker Halle]

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.

[Volker Halle]

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.

[Volker Halle]

AEF,

see previous discussion in ITRC:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?&threadId=787021

Volker.

[Hein van den Heuvel]

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

[John Gillings · Accepted solution]

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.

[Joseph Huber_1]

>>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.

[AEFAEF]

>Hein (RMS) van den Heuvel writes:
>
>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!

So how is this going to help answer my question?

>
>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?

1) I didn't say that. I said that the manual says that privileged
programs bypass user and supervisor logical names. AUTHORIZE is a
privileged program, but it does not bypass these access levels. Why?

2) Why, then, _is_ it an /EXEC logical name? Obviously DEC must have
had a good reason.

>How would that help?

I didn't say it would. But others have pointed out that it does help
with LOGINOUT.

>Security/Protection still comes from basic file object protection
>right no matter what flavor of logical?

But I thought the point of /EXEC was so that unprivileged users cannot
define their own logical names so as to redirect privileged programs
to reference incorrect files (or whatever else) that can somehow cause
a security problem, or more generally cause trouble otherhow.

Anyway--once again: The reference didn't say "SOME privileged programs
for some logical names at the programmers' discretion"; it said
"privileged programs". I took that to mean ALL privileged programs. I
thought it meant that privileged programs AUTOMATICALLY bypass the
less-secure access levels, not that the programmer would have to
implement such. This is clearly an exception and I was just asking why
and for clarification.

>
>SYSUAF is just an RMS indexed file, which you can manipulate with DCL,

Then why does LOGINOUT ignore user and supervisor names? After all (as
you wrote), SYSUAF is just a file. BTW, the LOGINOUT is a good
example. It appears to me that not having it bypass outer logical
names would allow a user with SYSPRV, but not SYSNAM, to replace the
current SYSUAF with his own and cause problems. But someone with
SYSPRV can just give himself SYSNAM? What am I missing here?

>Datatrieve, any program you choose to write, or indeed the provided
>AUTHORIZE executable which can be handy as it understands SYSUAF very
>well.

But that's not the point -- unless Datatrieve is a privileged program.

OK, so the doc should say something like this: Privileged programs
skip user and supervisor logical names as needed to prevent users from
causing trouble by their defining their own versions of the logical
names needed by the prilvilged programs.

OK.

>
>
>Best regards,
>Hein van den Heuvel

Are you the same Hein as in comp.os.vms? :-)

AEF

[Hein van den Heuvel]

Argh, this is confusing...

I thought I had seen this reply by before and was silly enough to react at that time.

I now realize that she indeed already replied to my snide remarks, but in a parallel discussion about SYSUAF ( http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1328254 )


Anyway... yes, the same Hein.

Cheers,
Hein.

[AEFAEF]

>Hein>AEF... no name/affiliation in recent posts.
>
>AEF> C'mon, the above doesn't help answer my question!
>
>Ah well, you may be wrong there.
>
>I know I have frequently NOT helped folks where I could because
>they have 'no name'. Why would I bother helping a nameless blob?

Why not? Wouldn't you want one to help you?

Blob? New, from IDG books: VMS for Blobs!

Insisting on me "identifying" myself seems a little on the nosy side,
which is why I resist. OK, maybe I'm paranoid. (This _is_ the
Internet, after all.)

And so much for the Golden Rule. As Shaw once wrote: "Do not do unto
others as you would expect they should do unto you. Their tastes may
not be the same."

>Where as I'll make an extra effort for folks I 'know'. We may
>well have met, and you may well be a nice person, contrary to
>what the prior reply suggest, but without a real name somewhere I
>can not figure it out. Maybe others are smarter.

Well, do you "know" the c.o.v. AEF? OK, I am he. I don't care about
such things for others. An example of what I dislike is when someone
posts a question, and we need more information to help him. But he
then becomes silent, yet many continue to post replies, usually in
futility (another example of differing tastes), whereas I quickly get
upset and leave the discussion.

>
>Yeah a name might well be made up And yeah, I've used non-names
>myself like for "Cmos" or Vaxman, JFM, NSR, notably in c.o.v.
>before. But for all those the real names are easily found. There
>may well be other assholes like me out there that have that one
>little bit of knowledge that could help you out but refuse to for
>this trivial reason.

I cannot comment on this without violating the forum rules. Send me an
email if you want an answer. (No curse words please. Remember the
forum rules!)

>
>AEF>> Then why does LOGINOUT ignore user and supervisor names?
>
>Because it has the potential, by virtue if its installed
>privileges to do powerful stuff, so it should not listen to
>untrustworthy advice.
>
>
>AEF>> But that's not the point -- unless Datatrieve is a
>privileged program.
>
>Authorize is not a privileged program IMHO, but you'll disagree
>with that. It happens to be installed with a privilege to do one
>particular thing. Big deal.

I didn't know AUTHORIZE was not "privileged". I was going by this:

$ INSTALL LIST AUTHORIZE

DISK$OPENVMS062:.EXE
AUTHORIZE;1 Prv
$

Please forgive me. I was looking for an example that clearly
demonstrates the documented behavior, which claims to include the
above.

>That's much like when you give a notes program netmbx in case a
>user does not have that. Big deal.

The doc just says "privileged", not whether or not you think it is a
big deal.

>
>Enough sillyness.
>Bigger problems to solve are waiting

Well, you can't work on big problems all the time. You have to sneak
in some fun every now and then, or you'll never have any!

>
>Best regards,
>Hein.

AEF