Bug 771255 - NIS groups are not located when user has a local group entry
NIS groups are not located when user has a local group entry
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Law
Fedora Extras Quality Assurance
Depends On:
Blocks: 782558
  Show dependency treegraph
Reported: 2012-01-02 18:04 EST by Michael
Modified: 2016-11-24 10:58 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 782558 (view as bug list)
Last Closed: 2012-01-13 01:01:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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):

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

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:


Stock was:

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


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 eric@christensenplace.us 2012-01-17 12:18:34 EST
I've cloned this bug for the release notes.

Note You need to log in before you can comment on or make changes to this bug.