SSSD / sssd

#2923 rfc2307bis: spurious errors show up in user group memberships.
Closed: Invalid Opened by howardg.

Closed: Invalid
Reopen Issue

The system is a Fedora 24 rawhide (cloud edition) running on Amazon EC2.

The issue shows up in SSSD 1.13.2 as well as SSSD 1.13.3, the attached log files were captured from SSSD 1.13.2.

To reproduce the issue:

  • Install packages:

dnf install openldap-servers openldap-clients

  • Edit schema /etc/openldap/schema/nis.ldif, change posixGroup from being a STRUCTURAL to AUXIALIRY, to enable rfc2307bis behaviour.
  • Install nis.ldif schema on LDAP server:

ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif

  • Allow users to modify and read LDAP database:

ldapmodify -Y EXTERNAL -H ldapi:/// -f privilege.ldif (see attachment)

  • Create user and group entities:

ldapadd -Y EXTERNAL -H ldapi:/// -f db.ldif (see attachment)

  • Run SSSD:

sssd -d 9 -f -c sssd.conf (see attachment)

Next, run the following commands repeatedly in random order:

  • id user1
  • id user2
  • id user3
  • su user1 -c 'id -G'
  • su user2 -c 'id -G'
  • su user3 -c 'id -G'

Observe that SSSD is able to correctly respond to each command, in the first 10-12 minutes:

  • uid=9000(user1) gid=10000 groups=10000,8000(All1)
  • uid=9001(user2) gid=10001 groups=10001,8000(All1)
  • uid=9002(user3) gid=10002 groups=10002,8001(All2)
  • 10000 8000
  • 10001 8000
  • 10002 8001

However, after 10-12 minutes, during which the system is completely idle, observe that SSSD begins to give incorrect response to those commands. In some occasions, user1 becomes member of both All1 and All2, and in some other occasions, user1 loses its auxiliary group memberships, and user3 becomes member of both All1 and All2:

  • uid=9000(user1) gid=10000 groups=10000
  • uid=9001(user2) gid=10001 groups=10001,8000(All1)
  • uid=9002(user3) gid=10002 groups=10002,8001(All2),8000(All1)
  • 10000
  • 10000 8000
  • 10000 8000 80001

(as shown in the attached log files).

What might be the issue? Thank you.

LDIF files, SSSD config, and log files
config+logs.tgz

I'm sorry about the delay. Pavel agreed he'd take a look.

owner: somebody => pbrezina

Hi, could you attach /var/lib/sss/db/cache_$DOMAIN.ldb both before and after the malfunction please?

Also, I wonder if this can be caused by having some groups without gid defined. Can you try to add gidNumber to all groups and see if that helps?

SSSD 1.13.3, cache and log files after incorrect responses, with additional GIDs in LDAP DB
1.13.3-more-gid-bad-cache+log.tgz

SSSD 1.13.3, cache and log files after incorrect responses, with less GIDs in LDAP DB
1.13.3-orig-conf-bad-cache+log.tgz

SSSD 1.13.3, cache and log files after good responses, with less GIDs in LDAP DB
1.13.3-orig-gid-good-cache+log.tgz

LDAP DB with GIDs assigned to all groups
db-with-more-gid.ldif

Hi Pavel, thanks for taking care of this.

It seems that SSSD 1.13.3 has reached rawhide, hence I upgraded SSSD and collected the cache files that you require.

In addition, I assigned GID numbers to all groupOfNames (excluding organisation units), however SSSD still makes incorrect responses after several minutes. See attachment 1.13.3-more-gid-bad-cache+log.tgz and db-with-more-gid.ldif​.

Now I noticed that you have two groups sharing cn:

  • cn=Staff,ou=Unit1,ou=UnixGroup,dc=my-domain,dc=com
  • cn=Staff,ou=Unit2,ou=UnixGroup,dc=my-domain,dc=com

Unfortunately, given how SSSD is design both these groups are stored into one object in our cache (simply name=Staff,cn=groups,cn=ldapdom,cn=sysdb). Can you try renaming those groups to different name and see if the problem persist?

Hello Pavel.

I admit that the LDAP database setup is indeed unusual.

Take user1 for example. user1 is a member of cn=Staff under ou=Unit1. Although cn=Staff is not a posix group, but cn=Staff is a member of cn=All1, which is a posix group, hence user1 belongs to the posix group.

I thought cn=Staff,ou=Unit2 should be different from cn=Staff,ou=Unit1. Would SSSD be able to distinguish between the two?

Hi, no, SSSD is not able to distinguish between those two and the behaviour is actually undefined.

Hi Pavel.

OK, would you like to consider supporting this setup in a future release of SSSD?

No matter what, thank you very much for taking care of this bug report.

Did renaming the groups helped?

Please, file an RFE (request for enhancement) ticket here and we will see if and when we implement it. Also, patches are always welcomed :-)

Hello Pavel.

Thank you very much, I can confirm that SSSD has no trouble giving correct responses to the commands when each Staff unit has unique CN.

Please feel free to close the ticket. I'll work on an RFE or maybe find time to work on a patch :P

I'm glad to hear that. Thank you.

resolution: => invalid
status: new => closed

Metadata Update from @howardg:
- Issue assigned to pbrezina
- Issue set to the milestone: NEEDS_TRIAGE

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3964

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.
Metadata
None
None
None
Normal
defect
SSSD
1.13.2
0
0
0
0
0
0
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.