On 06/06/2014 10:42 AM, Panu Matilainen wrote:
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
was just closed as invalid. I don't agree (and I also don't understand
the
closing comment).
The issue is that rpm --verify fails 50% of the time when one of the
RPM's
files is owned by a user 'aaa' who happens to share the same UID as
another
user 'bbb', even though the RPM is completely unchanged from its original
installation. This just seems wrong.
In UNIX the username -> UID relationship is a many-to-one mapping. Or
have
I been mistaken all these years?
Simply put, rpm --verify is incorrectly assuming that this
relationship is
one-to-one.
Either rpm has a bug or I'm missing something very basic...
Rpm has many bugs but I dont think this is one of them.
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.
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.
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.
As mentioned in the closing comment, there is no right or wrong answer
when there are duplicates. What rpm *could* do is try both ways and
issue warnings about duplicates though. It might not be entirely in
rpm's "domain" but...
- Panu -
_______________________________________________
Rpm-maint mailing list
[email protected]
http://lists.rpm.org/mailman/listinfo/rpm-maint
