Found this in a PMR and thought it was a great write-up. (In other words, don't give me credit for this.
)
Let me discuss the issue of file ownership in USS.
This is an issue that can be a little confusing as it
has to deal with how ownership information is stored in USS.
.
Ownership in the USS filesystem is stored as the numeric
UID and GID values. When you do an ls command (or view the file
ownership in ISHELL), for each file a SAF EXTRACT is done to
RACF to map the numeric UID (or GID) to a RACF userid or groupname.
.
When the owner UID of a file is 0 (or is a UID that is defined
to more then one userid), this can create some ambiguity in the UID
to userid resolution.
.
What happens when the SAF EXTRACT for UID 0 occurs is that
RACF will search its database for the first UID 0 that maps to a
userid and then returns that userid to USS.
.
Where the ambiguity in the UID 0 to userid resolution comes in
is the RACF cache. RACF will check its cache first to see if it can
satisfy the request. Because cache contents are always in a state
of flux, the outcome of the UID 0 to userid request might not produce
the same match each time the lookup is done.
.
To be clear, the file is owned by UID 0 and security checks are
based on the file's owning UID value. The displayed userid values in
ls or in ISHELL are for DISPLAY PURPOSES ONLY.
.
I hope that helps. It can be a little confusing, but the
bottom line is the the numeric UID or GID is what is used for
access checking in USS. The displayed userid/group is just done
for our benefit (as us humans like names instead of numbers),
but is not used for access checking.
.
This is really only an issue for UIDs that have been assigned
to more then one userid.
