Bug 782558

+++ 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):
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.

--- Additional comment from davide.rossetti.it on 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

--- Additional comment from davide.rossetti.it on 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.

--- Additional comment from davide.rossetti.it 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 aoliva 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 vendor-redhat on 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).

--- Additional comment from aoliva on 2012-01-11 17:09:12 EST ---

Thanks.  To narrow down debugging, is nscd enabled?

--- Additional comment from vendor-redhat on 2012-01-11 17:20:26 EST ---

No, nscd is not enabled.

--- Additional comment from aoliva 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 vendor-redhat on 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.

--- Additional comment from aoliva 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 aoliva 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 vendor-redhat 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 law 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.