Usernames

[Wim Van den Wyngaert]

While I was writing a script, I noticed some strange things.
1) AUDIT_SERVER runs with username AUDIT$SERVER
2) DTLOGIN runs with username
3) TCPIP$INETACP runs with username TCPIP$INETACP
4) NET$ACP runs with username DNA$SessCtrl

Why are these running with non-existing usernames ? Why are they not using SYSTEM ?

[Antoniov.]

Hello,
the process you post are unauthorized process, where unauthorized doesn't means cracker or hacker process but only system services without loginout validation (such as detached processes).
Theese process works as server of user request; for example to check any privilege a process have to read system file but user could not have access to it; so user client process send request to system server process that works in user environment and have system privileges to access system files.
User is a process waiting for authorization to login user session into system so have yet no user assigned.
Sorry for my english: I hope you can understand my post.

Bye
Antoniov

[Lokesh_2]

Hi,

See below explanation:

______________________________________

The fundamental system service that creates processes, SYS$CREPRC, does
not use SYSUAF.DAT in any way. There is no requirement that the UIC
specified to $CREPRC exists in SYSUAF.DAT and if by some hackery the
username of the _creator_ (which traditionally is mandatorily inherited by
the _created_ process) did not exist in SYSUAF.DAT, this still does not
cause $CREPRC a problem.

Now it is true that in the _special_ case where the image specified to
$CREPRC is LOGINOUT _and_ the flag specified to $CREPRC says _do_ look
at SYSUAF.DAT, then when LOGINOUT gets to run, SYSUAF.DAT becomes
relevant and the parameters for the process as specified in the call to
$CREPRC are largely irrelevant, being superseded by stuff looked up in
SYSUAF.DAT (and that includes the UIC).

And of course in the case of an interactive, batch or network login,
LOGINOUT is used and SYSUAF.DAT is used and the username is entered by
the user. So based on that experience, the customer's question makes
sense, while in the broader context, the question does not i.e. behaviour
for interactive/batch/network login does not apply to all process
creations, in particular not to detached process creations.

___________________________

HTH,
Best regards,
Lokesh

[Wim Van den Wyngaert]

I understand that the UIC doesn't has to exist. But where is the username coming from ? sys$creprc uses the username of the one who is using the system service. So where are these usernames coming from ? Is there a system service to do a "setusername" ?

[Jillychemung · Accepted solution]

There is no specific system service to set a username. All of these processes are privledged and thus have the ability to change their username field in the JIB - JIB$T_USERNAME. For detached processes, they get their username from the username of the process that created it (unless it is a priv'd process and changed it) and the UIC may not match that username.

[Mike Naime]

Actually, TCPIP processes do have "Named" accounts in the SYSUAF.DAT file.

If you have your UAF file slammed from a Multi-net site, and you are a TCPIP shop, you must re-create several accounts/proxies in order for NTP, FTP, SMTP... Etc to work correctly. Otherwise the services/processes will not startup at boot time because the account no longer exists.

When migrating a remote system from a client site, to our site, we run into this problem. They take the remote UAF file because there are hundereds of named users at that location, and I have about a dozen accounts to re-create.

Mike Naime

[Antoniov.]

Jilly,
welcome to VMS comunity.
Antoniov

[Jan van den Ende]

Wim,

while you are at it, ANOTHER thing is strange about it: the length of TCPIP$INETACP is GREATER than the normally allowed 12 characters!

Jan

[John Gillings]

Wim,

The (Username,UIC) pairs implicitly defined in UAF records may be used to create processes, but there is no requirement that a given process have a username or UIC that matches one defined in the UAF. A privileged process (IMPERSONATE) may create a process with any UIC at all, or (CMKRNL) change their username to any string they like (as described by Jilly).

Jan,

The "real" length limit in OpenVMS Usernames is 32 characters. It was increased from the original 12 in VMS V4.0. However, by that time the magic number "12" had been distributed too far and wide.

For a while you could define longer usernames using AUTHORIZE, but some things broke, so the NAMETOOBIG error was added to artificially re-impose the 12 character limit, but only in AUTHORIZE.

The username field in the UAF and in process data structures is 32 characters, and most things work correctly with long usernames. Correctly written code will specify the username length as PSB$S_USERNAME or UAF$S_USERNAME.

You may still be able to force a long username with $SETUAI, or by direct access to the UAF (unsupported!). It will "work", but some things may still break (MAIL was the most commonly reported utility that didn't work properly with long usernames back in V4 days, maybe it's been fixed by now?) I suspect that OpenVMS engineering hasn't had enough demand to justify attempting to qualify longer usernames.

[Wim Van den Wyngaert]

John (or someone else who is 40+),

I don't have very old systems any more. Has it always been like that (non existing user names) or did it change at a certain VMS version (my memories go back to 4.4 but I didn't check it then).