[Rpm-maint] Verify when two usernames use the same UID

Archie Cobbs archie at dellroad.org
Fri Jun 6 13:57:31 UTC 2014

On Fri, Jun 6, 2014 at 2:42 AM, Panu Matilainen <pmatilai at laiskiainen.org>

> On 06/05/2014 07:15 PM, Archie Cobbs wrote:
>> I'd like a second opinion from this list on http://rpm.org/ticket/872
>> which
> Pretty much the whole POSIX API assumes username <-> uid relation being
> one-to-one, getpwnam() and getpwuid() have no provisions to return more
> than one entry. What happens when duplicates are present is not described
> in any standard I know of (feel free to educate me if I'm just ignorant
> here) but I'd assume the behavior to be implementation dependent at best.

I don't know of any official standard, but duplicate usernames with the
same UID has been around for a long time. For example, FreeBSD for a long
time had usernames "root" and "toor" both with UID zero.

See also this discussion
which agrees with me.

The "standard", as such, is a de facto one: the kernel only cares about
UID's. Usernames are just a user-space convenience thing, whose semantics
are defined by the implicit behavior of various user-space utilities and

Obviously, for every username there must be a UID, but there is no official
requirement that there be a strictly 1:1 mapping.

It may not be considered "best practice" to have duplicates, but that's
irrelevant - whether there "should" be duplicates is a system admin policy
question, and it's not rpm's place to be in the business of asserting such
policy across the entire UNIX world.

Oh and just FWIW, what you describe in the ticket as the algorithm rpm
> should use is actually exactly what rpm does: it stat()'s the file, looks
> up the the username from st.st_uid and compares that with what is stored in
> the package for that file.

You're right, I got that totally backwards... what it should say is:

   1. Determine the UID of the installed file
   2. Determine the UID of the username that is supposed to own the file
   3. Compare #1 and #2 for equality

The above change would have the same behavior as currently in the
no-duplicates case, but would fix this bug in the duplicates case.

So this is an easy fix with no downsides, and I don't really see what the
problem is in fixing it even if you think people who have duplicate UID
usernames are bad sysadmins or whatever.

Come to think of it, in the scenario described in the ticket doing the
> exact opposite (looking up expected UID based on the username from package
> and comparing with on-disk UID) would do the right thing.
> But when there are multiple UIDs with same name, that would get unreliable
> results whereas the current "algorithm" gets it right.

I agree with the first sentence above - same as steps #1, #2, #3 mentioned
- but I don't understand the second sentence. Can you explain?

As mentioned in the closing comment, there is no right or wrong answer when
> there are duplicates.

I don't understand this comment. There is a clear right answer: if the RPM
manifest says "file X is owned by user A", then the file should verify if
and only if: "some user A exists, and the UID of file X equals the UID of
user A". This is well-defined and seems perfectly correct to me. It's
irrelevant whether or not some other user B with the same UID exists,
that's a totally separate issue/question.

An analogy: doesn't "John Smith" still live at "123 Main St" even if he
happens to have the nickname "Jack"?


Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20140606/2b1ee36c/attachment.html>

More information about the Rpm-maint mailing list