From owner-freebsd-stable@FreeBSD.ORG Mon Dec 13 13:26:22 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 ED03F1065774 for ; Mon, 13 Dec 2010 13:26:22 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 552AB8FC15 for ; Mon, 13 Dec 2010 13:26:22 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id E373946B17; Mon, 13 Dec 2010 08:26:21 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CE5388A01D; Mon, 13 Dec 2010 08:26:19 -0500 (EST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 13 Dec 2010 08:24:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20101102; KDE/4.4.5; amd64; ; ) References: <4BCE4D0F.2020807@quip.cz> <4BCE6615.9010707@quip.cz> <4D03AC1D.5070906@quip.cz> In-Reply-To: <4D03AC1D.5070906@quip.cz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012130824.33968.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Mon, 13 Dec 2010 08:26:19 -0500 (EST) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx Cc: Garrett Cooper , Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: /libexec/ld-elf.so.1: Cannot execute objects on / 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: Mon, 13 Dec 2010 13:26:23 -0000 On Saturday, December 11, 2010 11:51:41 am Miroslav Lachman wrote: > Miroslav Lachman wrote: > > Garrett Cooper wrote: > >> 2010/4/20 Miroslav Lachman<000.fbsd@quip.cz>: > >>> I have large storage partition (/vol0) mounted as noexec and nosuid. > >>> Then > >>> one directory from this partition is mounted by nullfs as "exec and > >>> suid" so > >>> anything on it can be executed. > >>> > >>> The directory contains full installation of jail. Jail is running > >>> fine, but > >>> some ports (PHP for example) cannot be compiled inside the jail with > >>> message: > >>> > >>> /libexec/ld-elf.so.1: Cannot execute objects on / > >>> > >>> The same apply to executing of apxs > >>> > >>> root@rainnew ~/# /usr/local/sbin/apxs -q MPM_NAME > >>> /libexec/ld-elf.so.1: Cannot execute objects on / > >>> > >>> apxs:Error: Sorry, no shared object support for Apache. > >>> apxs:Error: available under your platform. Make sure. > >>> apxs:Error: the Apache module mod_so is compiled into. > >>> apxs:Error: your server binary '/usr/local/sbin/httpd'.. > >>> > >>> (it should return "prefork") > >>> > >>> So I think there is some bug in checking the mountpoint options, > >>> where the > >>> check is made on "parent" of the nullfs instead of the nullfs target > >>> mountpoint. > >>> > >>> It is on 6.4-RELEASE i386 GENERIC. I did not test it on another release. > >>> > >>> This is list of related mount points: > >>> > >>> /dev/mirror/gm0s2d on /vol0 (ufs, local, noexec, nosuid, soft-updates) > >>> /vol0/jail/.nullfs/rain on /vol0/jail/rain_new (nullfs, local) > >>> /usr/ports on /vol0/jail/rain_new/usr/ports (nullfs, local) > >>> devfs on /vol0/jail/rain_new/dev (devfs, local) > >>> > >>> If I changed /vol0 options to (ufs, local, soft-updates) the above > >>> error is > >>> gone and apxs / compilation works fine. > >>> > >>> Can somebody look at this problem? > >> > >> Can you please provide output from ktrace / truss for the issue? > > > > I did > > # ktrace /usr/local/sbin/apxs -q MPM_NAME > > > > The output is here http://freebsd.quip.cz/ld-elf/ktrace.out > > > > Let me know if you need something else. > > > > Thank you for your interest! > > The problem is still there in FreeBSD 8.1-RELEASE amd64 GENERIC (and in > 7.x). > > Can somebody say if this is a bug or an expected "feature"? I think this is the expected behavior as nullfs is simply re-exposing /vol0 and it shouldn't be able to create a more privileged mount than the underlying mount I think (e.g. a read/write nullfs mount of a read-only filesystem would not make the underlying files read/write). It can be used to provide less privilege (e.g. a readonly nullfs mount of a read/write filesystem does not allow writes via the nullfs layer). That said, I'm not sure exactly where the permission check is failing. execve() only checks MNT_NOEXEC on the "upper" vnode's mountpoint (i.e. the nullfs mountpoint) and the VOP_ACCESS(.., V_EXEC) check does not look at MNT_NOEXEC either. I do think there might be bugs in that a nullfs mount that specifies noexec or nosuid might not enforce the noexec or nosuid bits if the underlying mount point does not have them set (from what I can see). -- John Baldwin