read only access using authorize ?

[Thomas Ritter]

Is it possible to provide read only access for a non-priviledged user to run authorize.
Running $mcr authorize implys read+write access.
Can this be changed ?

Thanks in advance
Tom

[Steven Schweda]

I see no easy way. You could, perhaps,
install AUTHORIZE.EXE with more privileges.
(AUTHORIZE HELP Files_Used suggests SYSPRV.)
I assume that this would open up some
horrible security holes.

It might make more sense to write a more
limited program to read the SYSUAF, and then
install that program with the required
privilege(s), subsystem identifier(s), or
whatever.

What problem are you trying to solve?

[Thomas Ritter]

Steve, the systems are being locked down. A number of groups have work habits whereby they check user records for such items as quotas, last login times and even if the account is enabled. Can be useful.
I like your idea of a simple replacement program which show one complete user listing. But I would like to avoid the work.

[Steven Schweda]

All I know is what's in the
freeware_readme.txt, but perhaps DIX could be
useful:

http://h71000.www7.hp.com/freeware/freeware70/dix/

[Volker Halle]

Tom,

would creating a SYSUAF.LIS file (UAF> LIST */FULL) from a repeating batch job satisfy the need of looking up some user account information from time to time ?

Volker.

[Antoniov.]

Thomas,
if your user group need individual information can simply use f$getjpi lex function.
I saw dix, there is a good information about sysuaf inside it.

Antonio
http://it.openvms.org

[Phil.Howell]

The vms_check tool includes a brief UAF listing in HTML table format, I'm sure you could adapt it to include quota information
Phil
http://h71000.www7.hp.com/openvms/journal/v7/vms_check_tool.html

[Hein van den Heuvel]

Sounds like you have an existing application that you want to disturb as little as possible, whether that application usage of the system makes much sense or not. (It doesn't make much send imho :-).

1) Things like account quota's don't change too often.
2) AUTHORIZE will follow USER mode logicals, but LOGINOUT will (obviously) only follow trusted logicals.

So perhaps a solution is to point a user mode logical for "sysuaf" to a reasonably up to date copy of the sysuaf file. Just copy (convert/share !) the file daily, or whenever significant changes are known to have been made.

hth,
Hein.

[Joseph Huber_1]

There is the $GETUAI system service, and there is freeware GETUAI utility to get individual fields and users from sysuaf using $GETUAI.

Could the habit of using authorize not be changed to use getuai, which could be installed with privilege without opening a security hole (at least not too wide) ?

[Jan van den Ende]

Well,

to add to (or just explain) the answer by Joseph:
$GETUAI needs SYSPRV, so that is no immediate answer, but the freeware GETUAI has already nicely implemented it. Installing THAT with sysprv pretty much gives what you want, and perhaps you could/should restrict of THAT by suitable identifiers.

hth

Proost.

Have one on me (maybe in Nashua?).

jpe

[Joseph Huber_1]

And the GETUAI utility can be found at process.com fileserver:
http://vms.process.com/fileserv_search.html
Enter GETUAI as the search term.

[Wim Van den Wyngaert]

GETUAI is not capable of showing the users. It shows you info about a known userid. So, show * is not in it.

Wim

[Robert Atkinson]

Thomas, we have a similar problem here, so I wrote a couple of scripts to allow non-privileged users to read UAF records.

DAYLISTUAF runs in batch with privileges and lists the records.

WHOUAF allows the users to search those listings.

Both are attached.

Rob.

[Robert Atkinson]

And here

[John Gillings]

Tom,

A quick and dirty way to do what you want...

First put an ACE on SYSUAF granting READ access to your non-privileged users.

When they want to read stuff, make a temporary COPY of SYSUAF (with both read and write access), then run AUTHORIZE against it:

READUAF.COM
$ COPY SYS$SYSTEM:SYSUAF.DAT -
SYS$SCRATCH:SYSUAF.DAT
$ DEFINE/USER SYSUAF SYS$SCRATCH:SYSUAF.DAT
$ DEFINE/USER SYS$INPUT SYS$COMMAND
$ MCR AUTHORIZE
$ DELETE SYS$SCRATCH:SYSUAF.DAT;*

This won't stop users from issuing AUTHORIZE commands which modify the file, but they'll only be executed against the scratch copy.

Note that in general it's not a good idea to give people read access to SYSUAF - it gives crackers a head start, as they know what usernames to probe. If you go this path, make sure the scratch copies are also protected from general access, and deleted after use.

[Dave Laurier]

Another way that still allows maximum security is to create a CAPTIVE account that is shared by all users under which a menu structure enables them to perform their most common actions.

For instance:

Menu

1. Check account last login
2. Check account status
...
etcetera

The DCL script that runs behind the CAPTIVE account can read the input from the menu, followed by for instance reading the account name and then execute the authorize utility with the appropriate command.

This prevents users from issuing commands within the authorize utility themselves and because of the behavior of the CAPTIVE account they will not be able to break out of the routine.

[Dave Laurier]

An example of a script that can be run under the CAPTIVE account in order to permit non-priviledged users to execute priviledged account management operations.

[Joseph Huber_1]

If You want to avoid specialized/captive accounts or batch jobs listing sysuaf to a common location, have a look into this program
http://wwwvms.mppmu.mpg.de/vmssig/src/for/last_login.for

It shows how to loop over all accounts (SYS$IDTOASC) and $getuai to extract whatever info.

The $idtoasc call is the key to wildcard $getuai.

[Richard J Maher]

Hi Thomas

It may not assist you in your current task but the attached file was used to allow Rdb users (with access to the stored function) access to a user's default directory.

FWIW.

Cheers Richard Maher

[Richard J Maher]

Hi (again) Thomas,

Having said that, Stephen Hoffman (of VMS engineering) says: -

1) "It's unsupported to call anything outside the kernel from inner-mode code."

2) If it's loaded and activated separately or otherwise not part of the kernel, it's not necessarily safe to call it from inner-mode

3) And in any event, inner-mode code cannot call RTL calls.

4) You can't call RTLs from inner-mode code.

5) You can't call user-mode code and user-mode RTLs from inner-mode code.

6) You can't call user-mode code from inner-mode code.

7) And AFAIK, it is not safe to call sys$getuai, since this call is
implemented as a UWSS and not as part of the kernel -- the LOADSS calls
needed to use outer-mode APIs as part of their operations, so the LOADSS
APIs are not directly part of the kernel.)
*****************************

Now, my name's Richard Maher and I say that on this particular subject Stephen Hoffman is talking crap. (This will inevitably trigger another sycophantic ITRC no-hoper to delete this entry, but hey, what can you do?

Regards Richard Maher

PS. See attached example of accessing SYSUAF directly if you believe Hoff.

PPS. Ask Hein what he thinks.

[Robert Gezelter]

Thomas,

I agree with John Gillings, if you must, create a scratch copy of the file locally with the appropriate permissions (WRITE).

Then do a DELETE/ERASE on the file when the operation is finished.

As to using a CAPTIVE command procedure, I would not say not to do it with the scratch copy, but I would not overly rely on CAPTIVE. Command scripts can have errors, and unless you are very careful, it is a potential hazard, which can be exploited. Remember, SYSUAF and RIGHTSLIST are the keystones of the entire security system.

- Bob Gezelter, http://www.rlgsc.com