#3464 id -G returns only the first group
Closed: Invalid 6 years ago Opened 6 years ago by mpa.

Listing the groups of a user is not working properly (using id or id -G).

I'm using an openldap LDAP server with a rfc2307 schema. The stanza for the LDAP configuration is:

[domain/company]
id_provider = ldap
ldap_schema = rfc2307
ldap_search_base = dc=company,dc=com
ldap_uri = ldap://ldap.company.com

/etc/nsswitch was configured to use sss for passwd, group and shadow.


Also getent group <group_name> seems to work.

Hi,
it is difficult to tell what's wrong without logs. Could you please follow https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html and attach the sssd debug logs? Thank you..

It turns out that commands like id, or groups uses the initgroups stanza for /etc/nssswitch to get the groups. My /etc/nssswitch didn't had an entry with that so I couldn't figured out right away. Hopefully after gdbing id and sssd-nss I found the issue.

I think it would be useful to add this in the Q/A and in your docs.

It turns out that commands like id, or groups uses the initgroups stanza for /etc/nssswitch to get the groups. My /etc/nssswitch didn't had an entry with that so I couldn't figured out right away. Hopefully after gdbing id and sssd-nss I found the issue.
I think it would be useful to add this in the Q/A and in your docs.

I am not really sure that I understand your misconfiguration.
By default initgroups is not in nsswitch.conf

[root@abf13e55b7ad /]# cat /etc/nsswitch.conf | grep -v "^#" | grep -v "^$"
passwd:      sss files systemd
shadow:     files sss
group:       sss files systemd
hosts:      files dns myhostname
bootparams: nisplus [NOTFOUND=return] files
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss
netgroup:   nisplus sss
publickey:  nisplus
automount:  files nisplus
aliases:    files nisplus

But in such case glibc will try all available modules (including sssd module). However, if there is "initgroups: files" in nsswitch.conf then glibc will look for groups only in /etc/groroup. So default configuration will work with glibc. And if you use other implementation of libc then you need to check its documentation.

Initgroups is used (at least with glibc) only if it's there, if it's not, then glibc falls back to group.

So this:

passwd: files sss
group: files sss
initgroups: files sss

is equivalent to:

passwd: files sss
group: files sss

Did you have initgroups out of sync with group?

As per adding this to docs -- the troubleshooting guide already says:

 If there is a separate initgroups database configured, make sure it either contains the ``sss`` module as well or comment the ``initgroups`` line completely

btw is it OK to close the bug?

This line about the initgroups is only in the AD section. As my backend is LDAP I didn't looked at this section.

To be clear the "Common AD provider issues" has a section about initgroups but not the "Common LDAP provider issues".

Finally I understood the reason of the issue. My user has a GID that is the stub group file that is distributed on all the machines. So when mgetgroups call the function getgrouplist one group is returned. Because of that mgetgroups didn't fallback on other issues like getgroups or getugroups.

Matthieu confirmed on IRC that it is not a bug in SSSD. And explicit "initgroups: files sss" helped to fix his corner case. (mixing default group from files and rest from sssd)

Metadata Update from @lslebodn:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

OK, since this is not a bug in sssd, I'm closing the ticket.

Metadata Update from @jhrozek:
- Issue status updated to: Open (was: Closed)

6 years ago

Metadata Update from @jhrozek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

6 years ago

(Sorry about the additional comment, I had the tab opened since yesterday and I thought Pagure would tell me about the mid-Air collision otherwise..)

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/4490

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.

Login to comment on this ticket.

Metadata