read only access using authorize ?

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