Univention Bugzilla – Bug 29915
caching by "extrausers" in nsswitch.conf fails in larger/complex environment
Last modified: 2013-01-25 10:31:25 CET
for customer details see Ticket#: 2012122021000664 The usage of "extrausers" in nsswitch.conf (as implemented by Bug #28361) fails in a specific customer environment: * more than 1000 users (which means this might be a duplicate of Bug #29393) * many "groups in groups" * an invalid configuration of local groupnames/gidNumbers in LDAP (i.e. "audio", "video") Calling "groups <user>" gives only a subset of memberships.
This issue could be caused by Bug #29393 as well.
I've checked the group file provided by the customer. The problem seems to be the gid numbers. All groups with a gid number in the range 1000 to 2000 are missing in the getent group output. With this "patch" I get the these missing groups: --- group.c.orig 2012-12-22 11:48:37.520001095 +0100 +++ group.c 2012-12-22 11:49:00.556001087 +0100 @@ -189,11 +189,11 @@ fseeko(stream, last_position, SEEK_SET); return NSS_STATUS_TRYAGAIN; } - if( t_gid < MINGID ) { - funlockfile(stream); - *errnop = 0; - return NSS_STATUS_UNAVAIL; - } + // if( t_gid < MINGID ) { + // funlockfile(stream); + // *errnop = 0; + // return NSS_STATUS_UNAVAIL; + // } funlockfile(stream); *errnop = 0; gr->gr_name = t_name; This should be fixed in this or in a different way together with the errata update for Bug #29393. (In reply to comment #0) > * an invalid configuration of local groupnames/gidNumbers in LDAP (i.e. > "audio", "video") The local system groups from LDAP are still missing in the getent group output. I think there is another check if the groups already exists. It is not a really good idea to define theses groups in local /etc/group AND in the LDAP directory.
> The local system groups from LDAP are still missing in the getent group output. > I think there is another check if the groups already exists. It is not a really > good idea to define theses groups in local /etc/group AND in the LDAP > directory. Die Entscheidung die Benutzer den Gruppen im LDAP zuzuordnen wurde ganz bewusst getroffen. Wir haben damals nirgens hinweise gefunden dass das nicht erlaubt sei. Wenn ich früher Gruppen per NIS verteilt habe habe ich die Gruppen ja auch teilweise doppelt gehabt. Was spricht technisch gegen dieses Vorgehen, ausser dass es nicht besonders elegant ist...
(In reply to comment #3) > > The local system groups from LDAP are still missing in the getent group output. > > I think there is another check if the groups already exists. It is not a really > > good idea to define theses groups in local /etc/group AND in the LDAP > > directory. > > Die Entscheidung die Benutzer den Gruppen im LDAP zuzuordnen wurde ganz bewusst > getroffen. Wir haben damals nirgens hinweise gefunden dass das nicht erlaubt > sei. Wenn ich früher Gruppen per NIS verteilt habe habe ich die Gruppen ja auch > teilweise doppelt gehabt. > > Was spricht technisch gegen dieses Vorgehen, ausser dass es nicht besonders > elegant ist... There are different ways how group membership can be resolved, even libc implements at least 2 ways to maintain backward compatibility. Some programs decided to implement it on their own. Each way handles those conflicts differently, so it is no "stable" solution to define groups oder users with conflicting names or IDs. I'd expect pam_groups (on client side) to be the better choice for your needs: http://linux.die.net/man/8/pam_group
(In reply to comment #2) The bug is already fixed in the newest version in Debian-sid: It's caused by /var/lib/extrausers/groups containing the numeric groups 24,25,29,44,134, which are located in the middle of said file. As soon as the first group with gid<500 is encountered when parsing the file, the search is aborted with NSS_STATUS_UNAVAIL, such that all following lines are ignored. <http://packages.debian.org/changelogs/pool/main/libn/libnss-extrausers/libnss-extrausers_0.6-3/changelog#version0.5-1> (In reply to comment #2) > The local system groups from LDAP are still missing in the getent group output. > I think there is another check if the groups already exists. It is not a really > good idea to define theses groups in local /etc/group AND in the LDAP > directory. The Name Service Switch (NSS) exits on the first found entry: /etc/nsswitch.conf configures "group: compat extrausers", which first looks up group information in /etc/group, then NIS, then ExtraUsers. The entry from the first source is returned. Please note that using "Matrikel numbers" as a user and group ID is a bad idea. Quoting from "man adduser.conf": > VALID NAMES > adduser and addgroup enforce conformity to IEEE Std 1003.1-2001, which > allows only the following characters to appear in group and user names: > letters, digits, underscores, periods, at signs (@) and dashes. The name > may no start with a dash. The "$" sign is allowed at the end of usernames > (to conform to samba). If a group oder user name starts with a digit, the C library can't distinguish if the given argument is supposed to be the numeric GID or the symbolic GID.
The relevant changes from 0.6 have been back-ported: +Check for gid < MINGID before loop instead of terminating the loop on the first line with gid < MINGID. +Skip empty lines and comment lines. +Fix stripping trailing whitespace. +Report proper error on out-of-memory-errors as required by NSS spec. +Open files CLO_EXEC for process safety. +Restore file position before unlock for thread safety. # getent group | wc -l 127 # wc -l /etc/group group 58 /etc/group 100 group 158 insgesamt # dpkg -i /root/libnss-extrausers_0.3-1.8.201301161943_amd64.deb # getent group | wc -l 153 Also a potential memory corruption problem has been fixed in 12_bug25656_initgroups_case_insensitive.patch: limit was used as MINIMUM, while it is the MAXIMUM! svn11306, libnss-extrausers_0.3-1.8.201301161943 ChangeLog: svn16105 \item A bug was fixed in the \ucsName{extrausers} name-service-switch module, which caused groups to disappear from the cached LDAP data (\ucsBug{29915}). YAML: 2013-01-16-libnss-extrausers.yaml svn16106
OK, it works: YAML: OK Changelog: OK 3.1-0errata: OK
http://errata.univention.de/3.1-errata22.html