SYSUAF

[Steven Schweda]

> or $ DEFINE/SYSTEM $1$DKA6 DRA2: ! whichever it is !

As I said, I'd add /EXECUTIVE_MODE.

My notes (older than 11 October 1999, in the
procedure I use to define users' home
devices) say:

(Executive mode is required for use by
utilities like MAIL and PHONE.)

I haven't tested this in the past decade, but
it might still be true, and might be relevant
here.

[Jim_McKinney]

> (Executive mode is required for use by
> utilities like MAIL and PHONE.)

and LOGINOUT.

[AEFAEF]

Steven Schweda is right. I neglected to add /EXECUTIVE. This is what HP recommends for public volumes.

Thanks for catching my goof!

[Richard W Hunt]

The correct solution has already been offered. This post is to corroborate and confirm that it works.

I have a bunch of moderatly small disks as the result of a complex history. Not required to understand that part. BUT what you need to know is that every one of those disks has a logical name defined /EXEC on the system.

On the failover system, I have the same number of same-sized disks but for technical reasons, the physical names are different. Doesn't matter. The logical names of all disks on the primary also exist on corresponding disks on the standby system.

And the crowning jewel is that SYSUAF devices are the logical names. So if I have to switch from primary to standby system, I just copy the SYSUAF.DAT and other files to the standby system's system disk. We do SAN-style replication on a regular basis. When we have to switch hosts, we only have the last 24 hours worth of incremental changes to apply and we can then reboot in the other site. So if you are in any situation even slightly similar to this, save yourself a major headache. NEVER use a physical device name except in your reboot scripts or from the system console when in console mode.

[Joseph Huber_1]

Just as an addendum:
If You happen to have Joe Meadows UAF program (VMS freeware), then You can get a list of users with home directories on a specific disk simply by
$ uaf/select=device=thedisk:/display=(user,device)

And UAF displays the disk also for Disusered users, other than AUTHORIZE show /BRIEF.

[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!

C'mon, the above doesn't 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) Why, then, _is_ it an /EXEC logical name?

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

>
>How would that help?

I didn't say it would.

>
>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 logicals to redirect privileged programs to reference
incorrect files that can somehow cause a security problem, or more
generally cause trouble otherhow.

Anyway--once again: The reference didn't say "SOME privileged
programs"; 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,
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 avoid allowing
users from performing actions for which they don't have assigned
privileges.

OK.

>
>
>Best regards,
>Hein van den Heuvel

AEF

[Hein van den Heuvel]

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

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.

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.

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

Enough sillyness.
Bigger problems to solve are waiting

Best regards,
Hein.