Why is /EXEC not needed for AUTHORIZE?

[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