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,
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
You're absolutely right that the sssd behaviour you've observed is
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
I think one has to be careful in applying rules that haven't
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
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
I think there is a right way.