VMS: UIC [1,1] - Need explanation

[Varsha]

Hello,

I am Varsha B from IBM. I just wanted to know if the UIC [1,1] is same as SYSTEM UIC. Below you can find the owner field of SYSUAF.DAT file as [1,1]. But [1,1] UIC does not exist on the system. Could you please elaborate what the UIC [1,1] exactly mean? Also Is it fine if we change the owner field for the below file to SYSTEM. Please help.

$ dir sys$system:sysuaf.dat/sec/prot

Directory SYS$COMMON:[SYSEXE]

SYSUAF.DAT;1 [1,1] (RWE,RWE,RWE,)

Total of 1 file.
$ mc authorize
UAF> sh [1,1]
%UAF-W-BADSPC, no user matches specification
UAF> exit
%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy database
%UAF-I-RDBNOMODS, no modifications made to rights database

[Jan van den Ende]

Varsha,

to begin with: WELCOME to the VMS forum!

The UIC [1,1] is quite often not named.
It is in the [1, ] group, meaning it automatically has SYSTEM rights.

Very often disks are initialised as belonging to [1,1], and under certain circumstances directories on it, and also files therein, inherit that ownership.

Many _PEOPLE+ prefer named ownerships, and that is why often an account (or only a UIC format identifier) for that value is created, and then I have always encountered the name SYSTEMBUILD for it.

(Maybe somebody here knows if that is or was, perhaps under certain circumstances, coming from Engeneering?)

Anyway, for the OS, only the numeric values are used anyway, so the presence or absence of a name for it has NO operational significance. (but humans ARE more at ease with named entities)

If you would like to make this system more human-friendly, you may execute (from a priv'd account):

$ MCR AUTHORISE ADD/IDENTIFIER SYSTEMBUILD /VALUE=UIC:[1,1] /ATTRIB=RESOURCE

Proost.

Have one on me.

jpe

[Varsha]

Thanks so much for your reply.
Also I would like to know if we can change the ownership of the files (who is currently having [1,1]) to [1,4] which is the system account. Please advise.

[Steven Schweda]

> so I would like to know if we can change
> the ownership of the files (who is
> currently having [1,1]) to [1,4] which is
> the system account.

What problem will this solve?

> Please advise.

Why go looking for trouble?

[Jan van den Ende]

Varsha,

Like Steven wrote, "What problem are you trying to solve" and "Why go looking for trouble"

but if you really want to

$ SET FILE /OWN=SYSTEM SYS$SYSTEM:SYSUAF.DAT

wil do the trick, and AFAIK is in itself pretty harmless.
However, DO NOT MAKE TYPO'S in such commands!!!

Proost.

Have one on me.

jpe

[Robert Gezelter]

Vatsala,

Let me add my welcome to the OpenVMS forum!

I would, however, not necessarily agree with changing the ownership of the files. I could easily agree with creating an accounting file entry for [1,1] in the SYSUAF.DAT (or at least creating an entry in RIGHTSLIST).

A quick check of my systems at various versions of OpenVMS show that some files are owned by SYSTEM ([1,4]) and some files are owned by [1,1]. This is normal. While file access by a privileged process should not be a problem, there is no guarantee that there is not some process on your system that would then experience a problem.

It is true that a quick check of the active processes shows no obvious processes running under [1,1], but that is far different from a guarantee.

So, with all due respect to my colleague, I would recommend leaving the protection set as it is. The definition of a rights identifier for [1,1] would make the listings "prettier", and have a far higher probability of being completely harmless.

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

[Steven Schweda]

> So, with all due respect to my colleague, I
> would recommend leaving the protection set
> as it is.

Which of your colleagues _recommended_
changing the ownership (not "the
protection")? "but if you really want to"
does not sound to me like a recommendation.

If I were looking to buy myself some trouble
this way, I'd probably make sure that I had
a good backup of the disk before I started
fiddling around with it, too.

[Hoff]

Somebody somewhere is apparently somewhat confused here, though there does exist a very subtle distinction of phrasing here.

[1,1] is a system UIC.

[1,1] is not the UIC of the SYSTEM user.

A "system uic" is any user with a UIC group with a UIC group of the maxsysgroup system parameter or less. SYSPRV privilege grants the same access; SYSPRV allows the possessor to have the same access as a user with a system UIC.

Central recommendation: Don't mess with this. Not without a whole lot better reason than what I've seen here so far. This system disk is configured appropriately.

This setting is likely a result of a system disk volume that was initialized with /SYSTEM, as most disks correctly are, and the creation operation having been run while SYSPRV or better privileges or with a system UIC, and thus the ownership is inherited.

Stephen Hoffman
HoffmanLabs LLC

-- -- --

INITIALIZE

/SYSTEM

Requires a system UIC or SYSPRV (system privilege) privilege.

Defines a system volume. The owner UIC defaults to [1,1].
Protection defaults to complete access by all ownership
categories, except that only system processes can create top-
level directories.

[John Gillings]

I'll try an explanation in different terms...

UICs in octal format [g,m] are a throwback from earlier operating systems, like RSX and RSTS. Being very small and limited, they had some dependencies on specific, hard coded UICs used for specific purposes. Although VMS has more flexibility, it inherited some dependencies as "standard conventions". In theory, they are arbitrary and could be changed, but in practice most folk just accept the out-of-the-box defaults.

The user "SYSTEM" has UIC [1,4]
There is no magic reason for the choice, consider it historic fact.

The default UIC for ownership of a system volume is [1,1]. This is in the same UIC GROUP as the user "SYSTEM", but is NOT the same UIC.

Again you should consider this historic fact with no particular reason.

All UICs with group numbers less or equal to SYSGEN parameter MAXSYSGROUP (default octal 10) have implicit SYSTEM privilege, so, in some senses are equivalent as they (mostly) imply the same privileged access to object.

There is no good reason to change any of these conventions. Although such changes could be expected to be benign, you can't be certain you don't run code which assumes the "normal" defaults and conventions and may break if confronted with unexpected changes.

I would strongly recommend AGAINST changes unless you have a compelling problem you're trying to solve and understand the potential impact of your changes.

[Wim Van den Wyngaert]

If you change the files from [1,1] to 1,4] a process that runs as user SYSTEM (=[1,4]) would access the file as OWNER too. This will not cause an access denial because the other protection fields will still be used if the owner isn't granting access.

But it could add additional access that is not wanted. E.g. owner has RWED and group, world and system only R.

Fwiw

Wim