From owner-freebsd-current@FreeBSD.ORG Wed Sep 7 23:45:26 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DDE6106566B for ; Wed, 7 Sep 2011 23:45:26 +0000 (UTC) (envelope-from ben@wanderview.com) Received: from mail.wanderview.com (mail.wanderview.com [96.255.48.138]) by mx1.freebsd.org (Postfix) with ESMTP id 63A608FC0A for ; Wed, 7 Sep 2011 23:45:26 +0000 (UTC) Received: from xykon.in.wanderview.com (xykon.in.wanderview.com [10.76.10.152]) (authenticated bits=0) by mail.wanderview.com (8.14.5/8.14.5) with ESMTP id p87NjOVq023470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 7 Sep 2011 23:45:24 GMT (envelope-from ben@wanderview.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1244.3) From: Ben Kelly In-Reply-To: <6DE0D1E4-E239-4791-BAEC-26BF635EFC5E@wanderview.com> Date: Wed, 7 Sep 2011 19:45:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DF549C7-51C0-4B9A-AB98-A7CED114AAE5@wanderview.com> References: <6DE0D1E4-E239-4791-BAEC-26BF635EFC5E@wanderview.com> To: current@freebsd.org X-Mailer: Apple Mail (2.1244.3) X-Spam-Score: -1.504 () ALL_TRUSTED,RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.72 on 10.76.20.1 Cc: Subject: Re: PAM/setloginclass link error in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 23:45:26 -0000 Just for the archives, this turned out to be a problem with updating the = ezjail basejail directory. I had run ezjail-admin update -i, but for = some reason it did not install the new libc.so.7 while it did install = pretty much everything else. Moving the old basejail out of the way and = installing a new basejail from scratch solved the problem. Its not = clear why ezjail's cpio command failed to update the libc.so.7 file in = the first place. Sorry for the noise. - Ben On Sep 5, 2011, at 7:17 PM, Ben Kelly wrote: > Hello all, >=20 > I upgraded my server today to a recent HEAD from its old sources from = about October 2010. After the upgrade I ran into an unusual problem. = I've worked around the issue for now, but I was wondering if anyone = could help me solve it correctly. >=20 > The problem is that all PAM related operations fail inside jails. = Initially I was getting this error in /var/log/messages: >=20 > passwd: in openpam_load_module(): no pam_unix.so found >=20 > That file was clearly there, however, so I dug into PAM and enabled = some debug in pam_dynamic.c. This got me the following message: >=20 > openpam_dynamic(): /usr/lib/pam_unix.so: /lib/libutil.so.9: Undefined = symbol "setloginclass" >=20 > This is a syscall added to the system in March, 2011. The link = process works fine normally, but fails in any jail. I went as far as = turning on rtld debug to verify it was giving up on libutil about half = way through when it could not resolve the symbol. I verified that = libc.so.7 was the same both inside and outside the jail. The = setloginclass symbol was defined as a WEAK reference. >=20 > Looking through past e-mail I noticed trasz@ said he was going to = explicitly put in code to support setloginclass from root in a jail. I = think I see this code in the prison privilege checking as well. Its = just not clear to me why its not linking. >=20 > To work around the issue I hacked setloginclass out of libutil for = now. This is clearly not ideal as I'm not sure when and where that will = blow up on me. It did let me log back into my e-mail, however. >=20 > For reference: >=20 > FreeBSD ianto.in.wanderview.com 9.0-BETA2 FreeBSD 9.0-BETA2 #1 r278M: = Mon Sep 5 18:54:58 UTC 2011 = root@ianto.in.wanderview.com:/usr/obj/usr/src/sys/SERVER i386 >=20 > The system is using zfs, nullfs, and ezjail to manage the jails. I = did upgrade my zfs pools to the latest version at this same time, but so = far I can't tie that to this problem. >=20 > Does anyone know why a jail would prevent rtld from linking in a = particular syscall? Any help or advice is greatly appreciated. >=20 > Thank you. >=20 > Ben