Red Hat Bugzilla – Full Text Bug Listing
|Summary:||NIS groups are not located when user has a local group entry|
|Product:||[Fedora] Fedora||Reporter:||Michael <vendor-redhat>|
|Component:||glibc||Assignee:||Jeff Law <law>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||16||CC:||aoliva, davide.rossetti, eric, fweimer, jakub, law, mfranc, schwab|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|:||782558 (view as bug list)||Environment:|
|Last Closed:||2012-01-13 01:01:35 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Michael 2012-01-02 18:04:57 EST
Description of problem: I am not 100% sure this is a glibc issue, but I think it is. In Fedora 16, I have NIS set up on a master and multiple clients. If a user is added to a local group, then their NIS groups are truncated and not available Version-Release number of selected component (if applicable): ypbind-1.33-9.fc16.x86_64 glibc-common-2.14.90-24.fc16.4.x86_64 glibc-devel-2.14.90-24.fc16.4.x86_64 glibc-2.14.90-24.fc16.4.i686 yp-tools-2.12-6.fc16.x86_64 glibc-2.14.90-24.fc16.4.x86_64 glibc-headers-2.14.90-24.fc16.4.x86_64 nsswitch.conf group: files nis initgroups: files nis netgroup: files nis How reproducible: User is in multiple groups in NIS: michael@bobafett> groups friends uucp dialout lock mythtv Add user to any random local group: [root@bobafett ~]# grep michael /etc/group plugdev:x:990:michael michael@bobafett> groups friends plugdev The default group of 'friends' is from NIS but is from the passwd entry. All others are lost. remove the local entry and the other entries return. I can easily reproduce this on the NIS master or slaves.
Comment 1 Davide Rossetti 2012-01-04 12:11:38 EST
similar problem: - YP server on an old Fedora core 1 - a bunch of users and groups, with UID and GID > 500 (old requirements) - on CentOS5.X/Fedora 14: uid=1002(rossetti) gid=100(users) groups=100(users),10(wheel),1004(apelinkdev),505(apelinkhw),1000(svnusers),500(rdevel),501(qcd),502(apeuser),503(media),504(apelink),600(apedevel),506(a4p),507(shapes) - on newly installed Fedora 16 desktop: uid=1002(rossetti) gid=100(users) groups=100(users) I tried to trim the /etc/login.defs on F16 desktop: UID_MIN 500 UID_MAX 60000 # System accounts SYS_UID_MIN 201 SYS_UID_MAX 499 # # Min/max values for automatic gid selection in groupadd # GID_MIN 500 GID_MAX 60000 # System accounts SYS_GID_MIN 201 SYS_GID_MAX 499
Comment 2 Davide Rossetti 2012-01-04 12:16:28 EST
additional info: - same desktop, before doing a full installation of F16 I did a preupgrade (F14 to F15 and then to F16) - everything was ok as of YP So it has to do with something which is preserved during upgrades, but overwritten on new installation. That's why I tried with that trimming of /etc/login.defs, which was not enough.
Comment 3 Davide Rossetti 2012-01-04 12:26:57 EST
if it is due to /etc/login.defs, this could be linked to 717109...
Comment 4 Alexandre Oliva 2012-01-10 14:44:05 EST
What do MINUID and MINGUI look like in /var/yp/Makefile ? How about Makefile.rpmnew, for those who upgraded from earlier releases?
Comment 5 Michael 2012-01-10 14:54:43 EST
All of the NIS groups in question are > 1000. My Makefile currently has: MINUID=0 MINGID=0 Stock was: MINUID=500 MINGID=500 I don't believe this should contribute to my issue since the data is in the NIS maps (not just in the files).
Comment 6 Alexandre Oliva 2012-01-11 17:09:12 EST
Thanks. To narrow down debugging, is nscd enabled?
Comment 7 Michael 2012-01-11 17:20:26 EST
No, nscd is not enabled.
Comment 8 Alexandre Oliva 2012-01-12 00:41:28 EST
Does it help if you add [SUCCESS=continue] between files and nis for group and initgroups? (I'm not sure it would, I'm just looking into a similar issue ATM and I thought that might offer some help here)
Comment 9 Michael 2012-01-12 11:30:05 EST
Unfortunately, this only makes things worse. michael@bobafett> groups friends uucp dialout lock mythtv Adding [SUCCESS=continue] to /etc/nsswitch.conf and adding michael back to a local group plugdev:x:990:michael yields this result: michael@bobafett> ssh bobafett groups friends 990 groups: cannot find name for group ID 990 Now it isn't even identifying local groups.
Comment 10 Alexandre Oliva 2012-01-12 13:49:47 EST
Yeah, I can see that the default nsswitch.conf in glibc has [SUCCESS=continue] only in initgroups, and I can duplicate the error of not finding local groups if I add [SUCCSES=continue] to the groups database too. I'll keep digging, thanks for the info so far.
Comment 11 Alexandre Oliva 2012-01-13 01:01:35 EST
Ok, so here's what I've found out so far: glibc's initgroups logic behaves differently depending on whether there is an initgroups entry in /etc/nsswitch.conf, or whether it's falling back to backward-compatible behavior using the group entry. This may explain differences between upgraded and fresh installs. What we want for F16 with NIS, to avoid the described problem, are such nsswitch.conf entries as: groups: files nis initgroups: files [SUCCESS=continue] nis I've verified that these behave as expected: “getent initgroups $user” collects group info for user from both files and nis, using glibc binaries off the trunk, as well as F16 glibc binaries (glibc-2.14.90-24.fc16.4 specifically). Although F15's getent doesn't support initgroups, F16's does, it runs on F15, using F15's nsl, nss and nis libs, and it collects information from both files and nis, even without [SUCCESS=continue] for initgroups. F16's, however, does not: if there is an initgroups entry without this directive, it will stop at the first lookup success. So please make sure the initgroups entry looks like the above in nsswitch.conf (best), or that it's not present at all, so that the inclusive backward-compatible behavior is used. From this investigation, I'm inclined to close this as NOTABUG; please reopen or add a note if that doesn't sound right.
Comment 12 Michael 2012-01-16 10:34:19 EST
I have tested the initgroups entry above and it does indeed resolve the problem I am seeing. I don't understand all of the technical details with initgroups, but this is definitely an unexpected change of behaviour. It would seem that this should be clearly documented somewhere to prevent others the churn of figuring out this problem.
Comment 13 Jeff Law 2012-01-16 14:11:16 EST
Ping'd the fedora-docs group to see if they want to pick this up. Seems like something that'd be good for the release notes, if they're still being updated for F16.
Comment 14 firstname.lastname@example.org 2012-01-17 12:18:34 EST
I've cloned this bug for the release notes.