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

[Willem Grooters]

Wim:

For security. These names do NOT exist in UAF as you pointed out so there is no way to gain access to the system using these names! These processes do not need to login to the system to work. They may force a login if required (as does TCPIP$INETACP).

[John Eerenberg]

Just to make sure I wasn't completely confused, I just used SDA on an Alpha VMS V7.3 system and the data structure JIB$T_Username is only 12 bytes long.

Yet, SDA's eval command on psb$s_username shows up as %x20 (32 decimal). Cool!

I thought I was pretty good with internals, but I can't find a reference to the PSB data structure . . .
Where is the process data structure for the 32 byte username?

Thanks,
john
-the memory goes when you reach 40-

[Hein van den Heuvel]

Surely the contents of the t_ field indicates 12 bytes are valid in the buffer, where the buffer size is 32.

Hein.

[John Gillings]

Wim,

>I don't have very old systems any more.
> Has it always been like that (non existing user names)

I don't have any pre V5 systems, but on V5.5 the username for AUDIT_SERVER is AUDIT$SERVER, UCX$INETACP is "INTERnet" and NETACP is "DECNET". On V5.5 SWAPPER has a null username, but it's "SYSTEM" on later versions.

I'm fairly sure the practice of labelling system processes with usernames that aren't in the UAF has been around since V1.0

Note that really there's no such thing as a "non-existent" username - the username of a process is arbitrarily, whatever is in the username field of the process data structures. This may or may not correspond to a record in the UAF.

John E:
>I thought I was pretty good with internals, but I can't find a reference to the PSB data structure . . .

The PSB is the PerSonaBlock, it's relatively new (V7), so not in old editions of the IDSM. It isolates all the fields relevant to thread persona. So, rather than changing all the scattered fields, personas can be set up independently and "plugged in" as required.

From SDA, try:

SDA> READ SYS$LOADABLE_IMAGES:SYSDEF
SDA> SET PROCESS/INDEX=pid-of-interest
SDA> FORMAT/TYPE=PCB PCB

you'll see PCB$AR_NATURAL_PSB pointing to your original persona.

SDA> FORMAT/TYPE=KTB KTB

(KTB is "KernelThreadBlock" note for a non-threaded process, this is the same structure as the PCB, just displayed using different symbols, some labels are different) you'll see KTB$AR_PSB pointing to the current persona.

SDA> FORMAT PSB

will display the PSB itself.

regarding JIB$T_USERNAME - yes it's only 12 characters long. However, it's only there for backwards compatibility. With the possibility of multiple personas in the same job tree, it no longer makes much sense and shouldn't be used or referenced by new code(indeed it behaves VERY strangely - the scheduler has special case code to keep the JIB$ and PSB$ username fields in synch, so writing directly to one or the other doesn't necessarily do what you expect. *Don't* try this at home! ;-)

[Ian Miller.]

I have a vague memory that the code that keeps the PSB and JIB fields in sync (for compatability with older code) is conditional on a flag somewhere but remember not where.

[Willem Grooters]

John,

...so writing directly to one or the other doesn't necessarily do what you expect. *Don't* try this at home! ;-)

Why not? It normally is the only place you can do it...