Hi Timo, On Wed, Feb 4, 2009 at 10:07 AM, Timo Sirainen <t...@iki.fi> wrote: > On Wed, 2009-02-04 at 09:47 +1300, Michael Kerrisk wrote: >> > In my real >> > program I got ENOENT for some reason. Anyway ENOENT still happens >> > if /proc is mounted but the executed file is outside the chroot. >> >> Yes. The entries in /proc/self/fd are symlinks, and these would refer >> to paths that probably don't exist in your chroot environment. > > Right. I originally thought that fexecve() would have been a kernel call > that internally were able to execute files outside chroot. I don't > actually even see many other benefits for that at all..
POSIX.1-2008 adds fexecve(), of which it says: [[ The purpose of the fexecve( ) function is to enable executing a file which has been verified to be the intended file. It is possible to actively check the file by reading from the file descriptor and be sure that the file is not exchanged for another between the reading and the execution. Alternatively, an function like openat( ) can be used to open a file which has been found by reading the content of a directory using readdir( ). ]] >> (If >> you have test program for this case, I'd be interested to see it, to >> run a few experiemnts.) > > The test program in my previous mail did the chrooting. Just compile it, > mkdir -p /tmp/foo/proc, mount --bind /proc /tmp/foo/proc and run it. So, I did some experimenting. It looks like the title of your report has things wrong: fexecve() can be used to exec a binary outside the chroot, but this won't work if, for example, the executable as dynamic dependencies that can't be satisfied within the chroot. To see this, open() a path that is a statically linked executable (so it doesn't have dynamic dependencies). I tested this: it works. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
