topic Extending SYSUAF.DAT in Operating System - OpenVMS

Extending SYSUAF.DAT

Jack Trachtman — Tue, 24 Jul 2007 12:50:30 GMT

Once again a security project has come up where I wish that the SYSUAF.DAT file had at least one (if not a few) fields that were reserved for customer use, so that I could add at least some additional info.

(I already use the Account Expiration field - which I understand no HP pgm uses - to store the account creatation date & time. Our security people use a script I wrote to create accounts and I plug that field with date & time + 1000 years).

Does anyone know of any other unused fields I might use or have any other suggestions (obviously I could create my own file w/additional info, but this could lead to possible synchronization problems. Besides, I only want to add some short, coded, text info.)

BTW - where is the SYSUAF.DAT record structure documented?

Thanks all

Re: Extending SYSUAF.DAT

Steven Schweda — Tue, 24 Jul 2007 13:19:06 GMT

I know nothing, but I do see

SYS$COMMON:[DECC$LIB.REFERENCE.SYS$STARLET_C]UAF070DEF.H

which says things like

/*++ */
/* User authorization file format */
/* Note: With the exception of the username and account name, */
/* all strings are blank padded counted strings. Username and */
/* account name are uncounted, blank padded. */
/*-- */

Re: Extending SYSUAF.DAT

Robert Gezelter — Tue, 24 Jul 2007 13:20:32 GMT

Jack,

You will find (the C version) of UAFDEF in SYS$LIB_C.OLB. There appears to be a "user-extensible area", but I have not researched it to verify if it is indeed usable.

I would seriously consider using an auxiliary file indexed by the UIC rights identifier. In a well managed system, it should be unique to a user, and you will avoid running into a problem when another utility has a divergent interpretation of a "reserved to user" field.

Please let me know if I have been unclear or can be of additional assistance.

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

Re: Extending SYSUAF.DAT

Hoff — Tue, 24 Jul 2007 13:55:56 GMT

There's a user-accessible free-form field in the SYSUAF file, and there's a way at it via $getuai and $setuai, or via direct RMS access. (It's over in the UAF*DEF module in SYS$STARLET_C.TLB, see UAF070$W_USRDATOFF, and see the UAI$_USER_DATA itemcode, for instance.)

I'd also tend to stay clear of SYSUAF, and usually prefer to use my own data file. This for reasons of flexibility, and to avoid collisions with other products using the user field and/or with other applications that access the records in SYSUAF. (It wasn't a very good design in various regards, and SYSUAF itself is no gem.)

As for synchronization of the parallel data with the live SYSUAF file, I had a pretty simple scheme that scanned SYSUAF nightly, and brought it back into synchronization with the parallel file. This was easily sufficient for my needs. If closer synchronization is required, enable and sniff the SYSUAF audit traffic for the messages of interest.

Stephen Hoffman
HoffmanLabs LLC

Re: Extending SYSUAF.DAT

Steven Schweda — Tue, 24 Jul 2007 13:59:59 GMT

> You will find (the C version) of UAFDEF in
> SYS$LIB_C.OLB.

That was ".TLB", right? In SYS$LIBRARY?

The newer stuff (module UAF070DEF) is
in SYS$LIBRARY:SYS$STARLET_C.TLB (or the
derived ".h" file cited above).

alp $ cc /version
HP C V7.1-015 on OpenVMS Alpha V7.3-2

There seem to be some differences in the fine
print, but both have members like:

__struct { /* default security class */
char uaf070$b_fill_6 [20];
} uaf070$r_def_class;
char uaf070$$$_fill_99 [44]; /* spare space */
char uaf070$$$_fill_100 [768]; /* user-extensible area */

for whatever that's worth.

Re: Extending SYSUAF.DAT

Hein van den Heuvel — Tue, 24 Jul 2007 17:36:01 GMT

UAI$_USER_DATA is there just for this reason. It works, it is supported. I have seen minor issues with some data records being improperly formatted, but that's easily remedied.
The biggest risk with UAI$_USER_DATA is that it is a free for all space. Some other application on your system might think it can own it outright. You can avoid that with a parallel (indexed) file, but that's more work for the system, and creates a (minor) synchronization challenge.

If you decide to bulk populate UAI$_USER_DATA then please be sure to convert your sysuaf file reasonably soon as the expansion is likely to cause massive bucket splitting.

Also, check out some prior c.o.v articles. You can find them readily with http://groups.google.com/group/comp.os.vms/search?group=comp.os.vms&q=hein+UAI$_USER_DATA

hth,
Hein.

Re: Extending SYSUAF.DAT

Jack Trachtman — Tue, 24 Jul 2007 18:11:40 GMT

Life can be so cruel sometimes...

As Hoff pointed out, the $setuai refers to a user accessible field of 255 characters! I've been looking for this for years! But - it's not supported. Here's the doc from the system services manual:

UAI$_USER_DATA
Sets up to 255 bytes of information in the user data area of the system user
authorization file (SYSUAF). This is the supported method for modifying the
user data area of the SYSUAF. HP no longer supports direct user modification of
the SYSUAF.

thanks all

Re: Extending SYSUAF.DAT

Steven Schweda — Tue, 24 Jul 2007 18:40:21 GMT

> HP no longer supports direct user
> modification of the SYSUAF.

Which I would interpret as prohibiting direct
UAF file I/O, and encouraging the use of "the
supported method" being described.

And I thought that _I_ was a pessimist.

Re: Extending SYSUAF.DAT

Hoff — Tue, 24 Jul 2007 20:18:13 GMT

UAI$_USER_DATA via $getuai and $setuai is supported.

Direct RMS modification to SYSUAF isn't.