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.
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
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.
if it is due to /etc/login.defs, this could be linked to 717109...
What do MINUID and MINGUI look like in /var/yp/Makefile ? How about Makefile.rpmnew, for those who upgraded from earlier releases?
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).
Thanks. To narrow down debugging, is nscd enabled?
No, nscd is not enabled.
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)
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.
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.
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.
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.
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.
I've cloned this bug for the release notes.
FEDORA-2023-90536f644e has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-90536f644e
FEDORA-2023-90536f644e has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.