From owner-freebsd-stable@FreeBSD.ORG Tue Mar 9 01:01:08 2010 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B01811065676 for ; Tue, 9 Mar 2010 01:01:08 +0000 (UTC) (envelope-from uranus@tinlans.org) Received: from tinlans.org (tinlans.org [220.133.199.45]) by mx1.freebsd.org (Postfix) with ESMTP id 3ACC88FC0A for ; Tue, 9 Mar 2010 01:01:08 +0000 (UTC) Received: from tinlans.org (localhost [127.0.0.1]) by tinlans.org (Postfix) with ESMTP id 843FCCF052; Tue, 9 Mar 2010 09:01:37 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tinlans.org; h= x-mailer:content-transfer-encoding:content-type:content-type :mime-version:date:date:subject:subject:in-reply-to:references :from:from:message-id:received:received; s=tinlans; t= 1268096497; bh=a1nDdP0MYUbIe9GMwe9DYZ9C6t04ZVJ08RLWDPVns/A=; b=E euMbNPbIn0fLzhoReoYoX+s0MsRfRzGSn4f6soJBn2zQOxiKNengbIEPI7mCt5QY 1Jg2ah6Cs4C7+ynO8yCeg== X-Virus-Scanned: amavisd-new at tinlans.org Received: from tinlans.org ([127.0.0.1]) by tinlans.org (tinlans.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x14WTWh6fQ7D; Tue, 9 Mar 2010 09:01:37 +0800 (CST) Received: from TinlansPC (TinlansPC [192.168.1.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tinlans.org (Postfix) with ESMTPSA id 4FFB1CF040; Tue, 9 Mar 2010 09:01:37 +0800 (CST) Message-ID: <80F42CAF32A14A1FB43B830AAF877A5A@TinlansPC> From: "Linghua Tseng" To: "Peter C. Lai" References: <20100309000826.GF4648@cesium.hyperfine.info> In-Reply-To: <20100309000826.GF4648@cesium.hyperfine.info> Date: Tue, 9 Mar 2010 09:00:49 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@freebsd.org Subject: Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2010 01:01:08 -0000 Yes, I'm sure. Here is the output of `diff -u /usr/src/etc/nsswitch.conf /etc/nsswitch.conf'. --- /usr/src/etc/nsswitch.conf 2010-03-08 09:04:25.000000000 +0800 +++ /etc/nsswitch.conf 2010-03-08 18:01:08.000000000 +0800 @@ -1,13 +1,13 @@ # # nsswitch.conf(5) - name service switch configuration file -# $FreeBSD: src/etc/nsswitch.conf,v 1.1.10.1 2009/08/03 08:13:06 kensmith Exp $ +# $FreeBSD: src/etc/nsswitch.conf,v 1.1 2006/05/03 15:14:47 ume Exp $ # group: compat -group_compat: nis +group_compat: ldap nis hosts: files dns networks: files passwd: compat -passwd_compat: nis +passwd_compat: ldap nis shells: files services: compat services_compat: nis The line `+:*::::::::' has already put into /etc/master.passwd, and the line `+:*::' has already put into /etc/group. In fact, my 2 machines were upgraded on different days. The 1st one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Mon Mar 8 10:21:45 CST 2010 The 2nd one's uname: 8.0-STABLE FreeBSD 8.0-STABLE #0: Wed Feb 24 03:46:38 CST 2010 Both of them cannot work properly. It can prove that this problem can be reproduced since 2/24 or earlier. Besides, I precisely followed the 11-step instructions that described in /usr/src/Makefile for upgrading my systems. To do mergemaster is never a big problem for me because I've used it since this script was born. /usr/local/etc/ldap.conf & /usr/local/etc/nss_ldap.conf are also consistent on my 4 machines. These settings works properly for my RELENG_7 machines, but RELENG_8 ones. By the way, I don't use nscd because it always caches users' login shell so that users cannot update it immediately. I also installed pam_ldap, and I have read this old topic: http://lists.freebsd.org/pipermail/freebsd-stable/2008-March/041393.html It says to set `bind_policy' to `hard' can resolve this issue, but it cannot work for me. -------------------------------------------------- From: "Peter C. Lai" Sent: Tuesday, March 09, 2010 8:08 AM To: "Ling-hua Tseng" Cc: Subject: Re: Supplementary groups on LDAP cannot work with RELENG_8 +nss_ldap > Unable to reproduce, at least on a brand new 8-R install. > Did you make sure you correctly merged /etc/nsswitch.conf during mergemaster? > > On 2010-03-08 09:07:12PM +0800, Ling-hua Tseng wrote: >> Today I upgraded 2 of my 4 machines from RELENG_7 to RELENG_8. >> Both of the 2 machines are just LDAP clients. >> My LDAP server is still running on RELENG_7, >> and the remained one is also a LDAP client. >> All of them were installed OpenLDAP-2.4.21 and nss_ldap-1.265_3. >> >> Before I upgrades my system, everything works properly. >> I added a group named `group1' on LDAP server, >> and then add a user named `user1' to this group. >> I can type `id user1' to see the following line: >> uid=3000(user1) gid=3000(user1) groups=3000(user1),10000(gorup1) >> >> Of course, now the following record is already my LDAP server: >> -- >> dn: cn=group,ou=group,dc=mydomain,dc=org >> objectClass: posixGroup >> cn: group1 >> gidNumber: 10000 >> memberUid: user1 >> -- >> >> After I upgraded these 2 machines from RELENG_7 to RELENG_8, >> to type `id user1' could only show the following information: >> uid=3000(user1) gid=3000(user1) groups=3000(user1) >> This user's supplementary group was gone, >> and he couldn't write any group-writable files which had gid 10000 one the 2 machines. >> But in my other 2 machines that running on RELENG_7, >> this problem is still not occured. >> >> I have logged the behaviors of RELENG_7 & RELENG_8. >> Here is the behavior when I type `id user1' on RELENG_7: >> -- >> conn=1007 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=user1))" >> conn=1007 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass >> shadowLastChange shadowMax shadowExpire loginClass >> >> conn=1007 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup))" >> conn=1007 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> >> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=3000))" >> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> >> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=3000))" >> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> >> conn=1007 op=4 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=10000))" >> conn=1007 op=4 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> -- >> In step 2, it tries to fetch out the full group list from my LDAP server. >> According to this information, it can know what user1's supplementary groups are. >> >> RELENG_8: >> -- >> conn=1008 op=2 SRCH base="ou=people,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixAccount)(uid=user1))" >> conn=1008 op=2 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass >> shadowLastChange shadowMax shadowExpire loginClass >> >> conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=3000))" >> conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> >> conn=1008 op=3 SRCH base="ou=group,dc=mydomain,dc=org" scope=1 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=3000))" >> conn=1008 op=3 SRCH attr=cn userPassword memberUid uniqueMember gidNumber >> -- >> It never tried to get the group list from LDAP server, >> hence it's impossible to know user1's supplementary groups. >> >> The client settings on RELENG_7 & RELENG_8 are fully consistent, >> so I don't think it's the problem of my config files. >> Since my 4 machines use the same version of nss_ldap, >> to downgrade nss_ldap's version for testing is meaningless. >> >> Should this problem is a base system's bug? >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > -- > =========================================================== > Peter C. Lai | Bard College at Simon's Rock > Systems Administrator | 84 Alford Rd. > Information Technology Svcs. | Gt. Barrington, MA 01230 USA > peter AT simons-rock.edu | (413) 528-7428 > =========================================================== > >