SYSTEM identifier not [1,4]

[SeanOBanion-G1]

OpenVMS 8.4 Integrity, patches current to update 6, migrated from Alpha system disk.

We have found the SYSTEM identifier is not [000001,000004] as expected, but [000202,000005].

The SYSTEM account does have UIC [1,4].

My questions are:

What impact does having the SYSTEM identifier not be [000001,000004]?

What should we look out for when we change it?

Further background.

On most systems, we have the account NDM_ADMIN that uses the same UIC as SYSTEM, namely [1,4].

Then we create an identifier, NDM_ADMIN (among other NDM identifiers), and grant it to SYSTEM, and the NDMADMIN account then also acquires the NDM_ADMIN identifier.

On one system, this fails. This is where the SYSTEM rights identifier is not [000001,000004] as expected, but [000202,000005].  There is an account with UIC [202,5], though there are no issues that we know of with that account.

On this system, after granting a rights identifier to SYSTEM, the NDMADMIN account does not acquire the identifier and cannot be used as it is on other systems. 

We believe that this is caused by the fact the SYSTEM identifier is not the same as the SYSTEM account UIC, and that NDMADMIN also uses the SYSTEM UIC.  We tested this by deleting the NDMADMIN account using UIC [1,4], and copying the SYSTEM account to NDMADMIN using /UIC=[1,5], which was an unused UIC.  We are then able to successfully grant the NDM_ADMIN identifier to the NDMADMIN account, and make use of the NDMADMIN account as expected.

Sean

[John McL]

A SYSTEM UIC of [202,5] is very odd. It sounds like the [1,4] UIC was modified for some reason.

Assuming that v8.4 on Integrity has the same SYSGEN parameters as v8.3 on Alpha, check you SYSGEN parameter MAXSYSGROUP.  That's what defines the maximum group UIC for "system accounts" .

See $ SYSGEN help Sys_params MAXSYSGROUP for details.  (I'd post it here but the formatting is likely to be mangled.)

If I was you I'd be changing the UIC for SYSTEM back to [1,4] as soon as possible, by changing the UIC then restarting the system.

(Note the qualifier above - I'm looking at v8.3 on Alpha, not 8.4 on Integrity - so I may be wrong.)  

[SeanOBanion-G1]

John,

It is the identifier SYSTEM that has the unexpected value.

The UIC for the SYSTEM account is [1,4], as expected.  If this were different, I think a lot of bad things would be happening.

I just not sure what kind of things will happen if the identifier is changed at this point.

Sean

[PJSeder]

I agree, if the SYSTEM account UIC was not [1,4], you might have quite a mess! :)

As long as you are not using the SYSTEM identifier in some ACL somewhere, it should be safe to change it. Since the issue seems to be tied to NDM, I would expect any potential fallout to be limited to the NDM (Connect:Direct) application.

You won't break OpenVMS by changing the [SYSTEM] identifier back to [1,4].

John

[John Gillings]

Sean,

  I agree with the other John, you should restore the SYSTEM identifier to its correct value [1,4]. Remember that many places in which identifiers are used, the binary value is stored (for example ACLs). The text name is translated at display time. So, any system defined uses are probably using the binary [1,4] value. These will be OK.

 There may be places where the new value has been stored. These may not work as expected (but then they probably wouldn't regardless of the name of the identifier!). I'd suggest also redefining the odd value with an obvious tag, something like:

UAF> ADD/IDENTIFIER THIS_IDENTIFIER_IS_NOT_CORRECT /VALUE=UIC:[202,5]

This should make instances of it more obvious. You can also use the /BY_OWNER qualifier for DIRECTORY to search for files owned  by the rogue value, and something like:

$ PIPE DIRECTORY/SECURITY disk:[000000...] | SEARCH SYS$PIPE THIS_IDENTIFIER_IS_NOT_CORRECT

to hunt for ACLs.

I'd also recommend working back through the audit journals to try and work out when the change was made, and by whom. Perhaps you can work out why it happened and what they were trying to achieve.