Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 751450 - Initgroups entry in nsswitch.conf should be commented out in the default config
Summary: Initgroups entry in nsswitch.conf should be commented out in the default config
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: 23
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: ---
Assignee: Siddhesh Poyarekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1366569
TreeView+ depends on / blocked
 
Reported: 2011-11-04 18:54 UTC by Andrew McNabb
Modified: 2016-08-31 10:45 UTC (History)
14 users (show)

Fixed In Version: 2.22-2.fc23
Doc Type: Bug Fix
Doc Text:
Clone Of: 750388
Environment:
Last Closed: 2015-08-26 04:33:38 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1363924 0 unspecified CLOSED getgrouplist() returns data not backed by the initgroups record of nsswitch.conf if nscd is running 2022-05-16 11:32:56 UTC

Internal Links: 1363924

Description Andrew McNabb 2011-11-04 18:54:00 UTC 
Cloned for glibc as requested by Tomas.

+++ This bug was initially created as a clone of Bug #750388 +++

Description of problem:

In Fedora 16, users' secondary groups are not being populated correctly. If a user runs "groups", only the primary group appears.

Version-Release number of selected component (if applicable):

sssd-1.6.2-5.fc16.x86_64

How reproducible:

always

Steps to Reproduce:
1.
2.
3.
  
Actual results:

Only the first group appears.

Expected results:

Groups should list all groups, not just the first group.

Additional info:

The backend is LDAP. The groups work correctly in Fedora 15 with the exact same configuration files and using the exact same LDAP server.

What other information would be helpful? Thanks.

--- Additional comment from jhrozek on 2011-11-01 05:19:36 EDT ---

(In reply to comment #0)
> What other information would be helpful? Thanks.

Debug logs. Please add "debug_level=10" to the domain section of sssd.conf, restart sssd and then attach /var/log/sssd/sssd_domain.log

--- Additional comment from sgallagh on 2011-11-01 07:16:02 EDT ---

I'd also like to see your (sanitized) sssd.conf and a little information about your LDAP layout.

--- Additional comment from amcnabb on 2011-11-01 11:24:17 EDT ---

Created attachment 531151 [details]
sssd_LDAP.log

I'm attaching sssd_LDAP.log with debug_level set to 10. By the way, the groups "wheel" and "guest" are both groups that the "amcnabb" user should be a member of.

--- Additional comment from amcnabb on 2011-11-01 11:25:53 EDT ---

Created attachment 531152 [details]
sssd.conf

--- Additional comment from amcnabb on 2011-11-01 11:30:38 EDT ---

(In reply to comment #2)
> I'd also like to see your (sanitized) sssd.conf and a little information about
> your LDAP layout.

Our users are in ou=people,dc=aml,dc=cs,dc=byu,dc=edu and our groups are in ou=group,dc=aml,dc=cs,dc=byu,dc=edu. The wheel group is cn=wheel,ou=group,dc=aml,dc=cs,dc=byu,dc=edu.  The ldif for the wheel group is:

"""
dn: cn=wheel
cn: wheel
gidNumber: 9999
objectClass: posixGroup
objectClass: top
structuralObjectClass: posixGroup
memberUid: root
memberUid: amcnabb
""" (with some additional memberUid entries)

The "guest" group is much the same, except its gid is 10001.

I'm not sure if this is the sort of LDAP layout information that you're looking for, so feel free to ask any additional questions.

--- Additional comment from sgallagh on 2011-11-01 11:37:59 EDT ---

Could you try setting 'enumerate = false', deleting/backing up your /var/lib/sss/db/cache_LDAP.ldb file and restarting SSSD?

I'd like to know if there might be a bug in the enumeration code that's causing your group memberships to disappear.

We mostly test with enumerate=false, because in most environments it's much faster (which is why it's the default)

--- Additional comment from amcnabb on 2011-11-01 11:44:12 EDT ---

Setting "enumerate=false" and deleting cache_LDAP.ldb doesn't seem to have made any difference.

(We only have about 25 users, so presumably enumerate=true shouldn't be slow.)

--- Additional comment from sgallagh on 2011-11-01 11:52:50 EDT ---

What happens if you do:
'getent group wheel'

Do you get the correct set of users back?

--- Additional comment from amcnabb on 2011-11-01 11:58:01 EDT ---

Yes, "getent group wheel" gives the correct set of users.

--- Additional comment from sgallagh on 2011-11-01 13:37:33 EDT ---

Andrew, what version of glibc do you have on the system?

rpm -q glibc

--- Additional comment from amcnabb on 2011-11-01 14:06:30 EDT ---

glibc-2.14.90-14.x86_64

--- Additional comment from amcnabb on 2011-11-03 11:46:36 EDT ---

I noticed today that PolicyKit successfully finds the members of the wheel group (polkit is configured with "AdminIdentities=unix-group:wheel"). It's interesting that both polkit and "getent group wheel" work.

Is there anything else that I should try to help track down the problem?

--- Additional comment from sgallagh on 2011-11-04 12:24:00 EDT ---

(In reply to comment #12)
> I noticed today that PolicyKit successfully finds the members of the wheel
> group (polkit is configured with "AdminIdentities=unix-group:wheel"). It's
> interesting that both polkit and "getent group wheel" work.
> 
> Is there anything else that I should try to help track down the problem?

Does the 'wheel' group also exist in /etc/groups?

--- Additional comment from amcnabb on 2011-11-04 12:44:57 EDT ---

No--our postinstall script removes it to make sure that there's no conflict.

--- Additional comment from amcnabb on 2011-11-04 12:55:35 EDT ---

Created attachment 531809 [details]
output from ldbsearch

I saw an older bug where the reporter was asked to run ldbsearch. I don't know if the information is helpful here, but I'll attach it just in case. I generated the attachment by running the following:

# ldbsearch -H /var/lib/sss/db/cache_LDAP.ldb |grep -i -v pass >~amcnabb/tmp/ldbsearch.txt
asq: Unable to register control with rootdse!
#

The only interesting thing I noticed in the output was that in the record for amcnabb, it correctly included "memberof: name=guest,cn=groups,cn=LDAP,cn=sysdb" and "memberof: name=wheel,cn=groups,cn=LDAP,cn=sysdb".

--- Additional comment from sgallagh on 2011-11-04 13:05:16 EDT ---

Andrew, what output do you get from 'id amcnabb'

I saw someone else reporting earlier today that 'groups' was missing groups for them too, but 'id username' had everything correct. If so, I think this is actually a glibc bug, not an SSSD bug.

Your LDB date looks perfect, so there's no reason it should not be reporting correctly.

--- Additional comment from amcnabb on 2011-11-04 13:08:40 EDT ---

Unfortunately, id is also showing incomplete information:

# id amcnabb
uid=10005(amcnabb) gid=10000(aml) groups=10000(aml)
#

--- Additional comment from amcnabb on 2011-11-04 13:13:40 EDT ---

I found it! It turns out that the following was in nsswitch.conf:

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

When I switched the last line to:

initgroups: files sss

it started working.

I'm thinking this might be an authconfig or anaconda bug.

--- Additional comment from sgallagh on 2011-11-04 13:15:53 EDT ---

(In reply to comment #18)
> When I switched the last line to:
> 
> initgroups: files sss


What the heck? When did they add an 'initgroups' line? That's definitely new...

Yeah, if that's being added by default now, we need to have authconfig make sure to handle this.

If you remove that line completely (or comment it out) do things work again?

--- Additional comment from amcnabb on 2011-11-04 13:21:09 EDT ---

(In reply to comment #19)
> What the heck? When did they add an 'initgroups' line? That's definitely new...

That's what I thought. :)
 
> Yeah, if that's being added by default now, we need to have authconfig make
> sure to handle this.
> 
> If you remove that line completely (or comment it out) do things work again?

If I comment out the line, it works correctly.

--- Additional comment from amcnabb on 2011-11-04 13:24:31 EDT ---

So is this a glibc bug for including an unnecessary line that complicates life in the standard nsswitch.conf, or is it a authconfig bug for not writing the new initgroups line?

Also, this should probably be documented in the Fedora 16 Release Notes, right?

--- Additional comment from sgallagh on 2011-11-04 13:26:25 EDT ---

Thanks for your patience and help in working this out. It looks like this is
something new that glibc added in F16 without advertising, and it's breaking
any non-files-based deployments on Fedora, because authconfig doesn't know to
update it.

I'm going to reassign this to authconfig.

--- Additional comment from amcnabb on 2011-11-04 13:30:24 EDT ---

I'm glad I could help. For now, I'm just removing the initgroups line in my postinstall because I can't think of any reason that it would be helpful to have initgroups be defined separately from groups.

--- Additional comment from tmraz on 2011-11-04 14:02:28 EDT ---

To me it seems like default nsswitch.conf from glibc should have it simply commented out if in this case the value is copied from the groups value.

I can certainly add the patch to authconfig to support it - it will be trivial. However such a change without any heads up notice is really not nice from glibc.

--- Additional comment from amcnabb on 2011-11-04 14:17:46 EDT ---

(In reply to comment #24)
> I can certainly add the patch to authconfig to support it - it will be trivial.
> However such a change without any heads up notice is really not nice from
> glibc.

Indeed. Is there anyone in particular from glic that should be cc'ed on this bug?

--- Additional comment from tmraz on 2011-11-04 14:49:27 EDT ---

Please clone this bug for glibc component.
Comment 1 Tomas Mraz 2011-11-04 19:22:01 UTC 
1. The addition of initgroups entry into nsswitch.conf should have been properly announced.

2. For backwards compatibility it should be commented out in the default nsswitch.conf
Comment 2 Simo Sorce 2011-11-04 19:39:09 UTC 
Andreas can you please explain what this initgroups is ?

Also can we please prepare an update to push right after GA to back this change out ?

*IF* there is a good reason to have an option like this it must:
A) be discussed widly with stakeholders (at least the main nss_* modules maintainers)
B) Be backwards compabible *BY DEFAULT*

I am too angry to better articulate any request, but a prompt discussion about this *feature* is highly desirable.
Comment 3 Adam Williamson 2011-11-05 00:15:31 UTC 

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Fedora Update System 2011-11-10 12:48:10 UTC 
glibc-2.14.90-15.1 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/glibc-2.14.90-15.1
Comment 5 Fedora Update System 2011-11-11 01:21:53 UTC 
Package glibc-2.14.90-15.1:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-15.1'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15723
then log in and leave karma (feedback).
Comment 6 Fedora Update System 2011-11-12 03:29:07 UTC 
Package glibc-2.14.90-15.2:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-15.2'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15723
then log in and leave karma (feedback).
Comment 7 Fedora Admin XMLRPC Client 2011-11-14 19:15:44 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Update System 2011-11-14 22:25:05 UTC 
Package glibc-2.14.90-16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.14.90-16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-15723
then log in and leave karma (feedback).
Comment 9 Fedora Update System 2011-11-17 23:02:01 UTC 
glibc-2.14.90-18 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/glibc-2.14.90-18
Comment 10 Robert Buffington 2011-11-26 20:00:19 UTC 
I still have a problem with secondary LDAP and local groups. I am now a member of my LDAP groups after updating to authconfig-6.1.16-2.fc16 and running "authconfig -updateall". However, if I add myself to any group in /etc/group, the result is that I am now only a member of the local groups and not any of the LDAP groups.

/etc/nsswitch.conf (after applying authconfig-6.1.16-2.fc16 [bug 750388]):
initgroups:  files sss

without "me" being a member of any group in /etc/group:

$ groups
me software security staff ftpadmin sysadmin

adding me to a group in /etc/group
apache:x:48:me

$ groups
me apache

Removing the initgroups line from /etc/nsswitch.conf exhibits expected behavior, as reported above:

$ groups
me apache software security staff ftpadmin sysadmin
Comment 11 Simo Sorce 2011-11-27 16:24:53 UTC 
Robert, the correct configuration is to comment out initgroups entirely.

Authconfig tries it's best to respect what the admin may have set, unfortunately the initgroups is simply terminally stupid and completely breaks any existing configfuration no matter what as it completely changes the semantics of the initgroups call.

The glibc maintainer messed up badly and initgroups is enabled by default in F16 GA, so you may have to manually remove it.
Comment 12 Tomas Mraz 2011-11-28 07:21:38 UTC 
If you remove the entry, authconfig will not readd it.

Unfortunately the semantics of the initgroups is different from the other entries and authconfig will have to be changed to respect it. I really wonder whether it wouldn't be the best idea to always just remove the entry by authconfig.
Comment 13 Simo Sorce 2011-11-28 14:02:37 UTC 
Tomas,
what about adding a authconfig option like --preserve-initgroups and otherwise always remove it ?
In almost all cases you would never want to use initgroups as defined in glibc as it makes little to no sense.
Comment 14 Tomas Mraz 2011-11-28 14:14:44 UTC 
I'm not sure if that would really make sense to have this option - basically if you want to modify the pam and nsswitch.conf files manually, you should not use the authconfig at all.

So I'll probably remove the entry altogether and unconditionally.

Hopefully glibc will keep the old backwards compatible semantics when the entry is not there in future.
Comment 15 Simo Sorce 2011-11-28 14:30:47 UTC 
Works for me.
Comment 16 Adam Williamson 2011-12-15 01:44:22 UTC 
I believe we still need a fix for this in glibc. AIUI the desired fix is for the initgroups line to be dropped entirely from the default /etc/nsswitch.conf file, right Tomas?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 17 Tomas Mraz 2011-12-15 07:29:29 UTC 
Yes, or it can be left there commented out with an appropriate comment about the semantic difference between initgroups entry and the other entries.
Comment 18 Fedora End Of Life 2013-01-17 02:14:53 UTC 
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 19 Fedora Admin XMLRPC Client 2013-01-28 20:07:58 UTC 
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 20 Fedora End Of Life 2013-02-14 03:04:09 UTC 
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 21 Carlos O'Donell 2013-02-14 13:11:05 UTC 
Reopening since this bug still needs triaging and answering.

Moving to rawhide to see if we can reproduce.
Comment 22 Fedora End Of Life 2013-04-03 19:48:25 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 23 Siddhesh Poyarekar 2014-10-10 10:13:33 UTC 
The SSSD nss plugin already implements initgroups_dyn support, so I assume what initgroups is for is already known.

It looks like the patch to remove the initgroups line from the default nsswitch.conf was committed to the fedora/master branch in the upstream glibc[1] repository but it was never pulled into Fedora.  When we finally discovered the branches and their use (in 2013), I did not notice this until I came across this bug.

If the sssd initgroups_dyn callback is an optimal implementation for initgroups (i.e. it is faster than just using groups as fallback), then it might make sense to keep the initgroups line in place like this:

  initgroups: files [SUCCESS=continue] sss

authconfig will then have to support this.  The files implementation for initgroups is not really any better than groups AFAIR, so the only other benefits of initgroups are visible when one uses nscd (not default) or uses the nssdb (again, not default).

If it doesn't matter, I'll just remove the line from nsswitch.  Let me know what is preferable.

[1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=3b819160
Comment 24 Jan Kurik 2015-07-15 15:13:07 UTC 
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 25 Siddhesh Poyarekar 2015-08-12 12:24:07 UTC 
(In reply to Siddhesh Poyarekar from comment #23)
> If it doesn't matter, I'll just remove the line from nsswitch.  Let me know
> what is preferable.

Ping?
Comment 26 Tomas Mraz 2015-08-12 13:24:41 UTC 
I'd say just remove it.
Comment 27 Siddhesh Poyarekar 2015-08-14 08:12:00 UTC 
Pushed in rawhide and I've also got an f23 build going.
Comment 28 Fedora Update System 2015-08-17 06:56:27 UTC 
glibc-2.22-2.fc23 has been submitted as an update for Fedora 23.
https://admin.fedoraproject.org/updates/glibc-2.22-2.fc23
Comment 29 Fedora Update System 2015-08-19 08:13:26 UTC 
Package glibc-2.22-2.fc23:
* should fix your issue,
* was pushed to the Fedora 23 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing glibc-2.22-2.fc23'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-13713/glibc-2.22-2.fc23
then log in and leave karma (feedback).
Comment 30 Fedora Update System 2015-08-26 04:33:34 UTC 
glibc-2.22-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.