Red Hat Bugzilla – Bug 782558
NIS groups are not located when user has a local group entry
Last modified: 2012-05-04 09:49:18 EDT
+++ This bug was initially created as a clone of Bug #771255 +++
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):
group: files nis
initgroups: files nis
netgroup: files nis
User is in multiple groups in NIS:
friends uucp dialout lock mythtv
Add user to any random local group:
[root@bobafett ~]# grep michael /etc/group
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.
--- Additional comment from email@example.com on 2012-01-04 12:11:38 EST ---
- 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:
# System accounts
# Min/max values for automatic gid selection in groupadd
# System accounts
--- Additional comment from firstname.lastname@example.org on 2012-01-04 12:16:28 EST ---
- 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.
--- Additional comment from email@example.com on 2012-01-04 12:26:57 EST ---
if it is due to /etc/login.defs, this could be linked to 717109...
--- Additional comment from firstname.lastname@example.org on 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?
--- Additional comment from email@example.com on 2012-01-10 14:54:43 EST ---
All of the NIS groups in question are > 1000.
My Makefile currently has:
I don't believe this should contribute to my issue since the data is in the NIS maps (not just in the files).
--- Additional comment from firstname.lastname@example.org on 2012-01-11 17:09:12 EST ---
Thanks. To narrow down debugging, is nscd enabled?
--- Additional comment from email@example.com on 2012-01-11 17:20:26 EST ---
No, nscd is not enabled.
--- Additional comment from firstname.lastname@example.org on 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)
--- Additional comment from email@example.com on 2012-01-12 11:30:05 EST ---
Unfortunately, this only makes things worse.
friends uucp dialout lock mythtv
Adding [SUCCESS=continue] to /etc/nsswitch.conf and adding michael back to a local group
yields this result:
michael@bobafett> ssh bobafett groups
groups: cannot find name for group ID 990
Now it isn't even identifying local groups.
--- Additional comment from firstname.lastname@example.org on 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.
--- Additional comment from email@example.com on 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.
--- Additional comment from firstname.lastname@example.org on 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.
--- Additional comment from email@example.com on 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.
Will review whether appropriate. Probably not.
Will not be doing another release for F16