Date: Mon, 13 Dec 2010 08:24:33 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Garrett Cooper <yanefbsd@gmail.com>, Miroslav Lachman <000.fbsd@quip.cz> Subject: Re: /libexec/ld-elf.so.1: Cannot execute objects on / Message-ID: <201012130824.33968.jhb@freebsd.org> In-Reply-To: <4D03AC1D.5070906@quip.cz> References: <4BCE4D0F.2020807@quip.cz> <4BCE6615.9010707@quip.cz> <4D03AC1D.5070906@quip.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201012130824.33968.jhb>