On 9/24/18 4:12 PM, Beale (US), Gareth wrote: >> I’m not so sure it would be a good idea to support this, honestly. > > Well that rather depends on what you mean by "this". I was reporting > a problem that seemed an inconsistency to me. Either multiple groups > with the same GID are supported, or they aren't. The current > implementation is inconsistent in its response over time, and it > flags an error and then fails - that should not happen in either > scenario.
You're absolutely right that the sssd behaviour you've observed is
inconsistent.
That's why Jakub Hrozek wrote:
> btw it’s a good question to ask why isn’t the check done on saving
> the group. I thought it was and I see code that checks for ID
> uniqueness andeven a test..
So for me it boils down to:
Multiple group entries with same GID are not supported in sssd and
should never be added to the cache. Why it happened in your case has to
be examined.
> I think one has to be careful in applying rules that haven't been
> applied in the past. Since using GIDs in this way is a "hack" but has
> been used in the past, albeit with the expectation that some corners
> don't work properly, changing the behaviour needs to be carefully
> thought out. The example case you state does produce differing
> results with nss_ldap, so should that really change?
The question here is whether the behaviour of nss_ldap shall be
considered as the standard reference. Personally I don't think so.
Looking at RFC 2307:
( nisSchema.1.1 NAME 'gidNumber'
DESC 'An integer uniquely identifying a group in an
administrative domain'
EQUALITY integerMatch SYNTAX 'INTEGER' SINGLE-VALUE )
The wording in DESC implies that Luke Howard assumed 'gidNumber' to be
unique even though he did not enforce this when implementing nss_ldap.
After thinking more about this I'd consider this inconsistency to be a
real security risk, maybe not in your particular deployment, but in
general. So I'd never trust a NSS implementation like this.
> I suspect it is the way it is because there's no clear "right" way to
> handle it.
I think there is a right way.
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
