Debian Bug report logs - #514043
manpages-dev: fexecve() should mention it doesn't work inside chroot

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Timo Sirainen <tss@iki.fi>

To: submit@bugs.debian.org

Subject: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Tue, 03 Feb 2009 12:58:40 -0500

Package: manpages-dev
Version: 3.01-1
Severity: wishlist

To prevent other people from wasting their time with fexecve(), I suggest
adding something like this to the description:

Linux implements fexecve() by executing the binary via proc filesystem,
so /proc needs to be mounted and available during the fexecve() call.

And for ERRORS:

ENOENT: /proc filesystem not available.

ref: http://lkml.org/lkml/2006/12/27/140

-- System Information:
Debian Release: lenny/sid
  APT prefers intrepid-updates
  APT policy: (500, 'intrepid-updates'), (500, 'intrepid-security'), (500, 'intrepid')
Architecture: i386 (i686)

Kernel: Linux 2.6.27-9-generic (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages manpages-dev depends on:
ii  manpages                      3.01-1     Manual pages about using a GNU/Lin

manpages-dev recommends no packages.

-- no debconf information

Message #10 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>, 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 4 Feb 2009 07:42:21 +1300

Hi Timo,

On Wed, Feb 4, 2009 at 6:58 AM, Timo Sirainen <tss@iki.fi> wrote:
> Package: manpages-dev
> Version: 3.01-1
> Severity: wishlist
>
> To prevent other people from wasting their time with fexecve(), I suggest
> adding something like this to the description:
>
> Linux implements fexecve() by executing the binary via proc filesystem,
> so /proc needs to be mounted and available during the fexecve() call.

I can see some merit in adding a sentence like this, but:

> And for ERRORS:
>
> ENOENT: /proc filesystem not available.
>
> ref: http://lkml.org/lkml/2006/12/27/140

surely the error is ENOSYS (see the glibc source), which is already
documented in the man page?

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

Message #15 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Timo Sirainen <tss@iki.fi>

To: mtk.manpages@gmail.com

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Tue, 03 Feb 2009 15:12:50 -0500

[Message part 1 (text/plain, inline)]

On Wed, 2009-02-04 at 07:42 +1300, Michael Kerrisk wrote:
> > To prevent other people from wasting their time with fexecve(), I suggest
> > adding something like this to the description:
> >
> > Linux implements fexecve() by executing the binary via proc filesystem,
> > so /proc needs to be mounted and available during the fexecve() call.
> 
> I can see some merit in adding a sentence like this, but:
> 
> > And for ERRORS:
> >
> > ENOENT: /proc filesystem not available.
> >
> > ref: http://lkml.org/lkml/2006/12/27/140
> 
> surely the error is ENOSYS (see the glibc source), which is already
> documented in the man page?

Well, what I did was:

1. open() an executable
2. chroot() to empty directory
3. drop root privileges
4. fexecve()

And fexecve() return ENOENT. So I was assuming it's because there was
no /proc in the empty dir..

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 4 Feb 2009 09:17:23 +1300

On Wed, Feb 4, 2009 at 9:12 AM, Timo Sirainen <tss@iki.fi> wrote:
> On Wed, 2009-02-04 at 07:42 +1300, Michael Kerrisk wrote:
>> > To prevent other people from wasting their time with fexecve(), I suggest
>> > adding something like this to the description:
>> >
>> > Linux implements fexecve() by executing the binary via proc filesystem,
>> > so /proc needs to be mounted and available during the fexecve() call.
>>
>> I can see some merit in adding a sentence like this, but:
>>
>> > And for ERRORS:
>> >
>> > ENOENT: /proc filesystem not available.
>> >
>> > ref: http://lkml.org/lkml/2006/12/27/140
>>
>> surely the error is ENOSYS (see the glibc source), which is already
>> documented in the man page?
>
> Well, what I did was:
>
> 1. open() an executable
> 2. chroot() to empty directory
> 3. drop root privileges
> 4. fexecve()
>
> And fexecve() return ENOENT. So I was assuming it's because there was
> no /proc in the empty dir..

Can you provide a very simple test program?  In my tests, I am seeing
ENOSYS, as I would expect from reading the source.`


-- 
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

Message #25 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Timo Sirainen <tss@iki.fi>

To: mtk.manpages@gmail.com

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Tue, 03 Feb 2009 15:22:24 -0500

[Message part 1 (text/plain, inline)]

On Wed, 2009-02-04 at 09:17 +1300, Michael Kerrisk wrote:
> >> > And for ERRORS:
> >> >
> >> > ENOENT: /proc filesystem not available.
> >> >
> >> > ref: http://lkml.org/lkml/2006/12/27/140
> >>
> >> surely the error is ENOSYS (see the glibc source), which is already
> >> documented in the man page?
> >
> > Well, what I did was:
> >
> > 1. open() an executable
> > 2. chroot() to empty directory
> > 3. drop root privileges
> > 4. fexecve()
> >
> > And fexecve() return ENOENT. So I was assuming it's because there was
> > no /proc in the empty dir..
> 
> Can you provide a very simple test program?  In my tests, I am seeing
> ENOSYS, as I would expect from reading the source.`

Weird. I'm also getting ENOSYS now in my test program. 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. Test
program:
#define _GNU_SOURCE
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>

int main(void)
{
	extern char **environ;
	char *argv[] = { "ls", NULL };
	int fd = open("/bin/ls", O_RDONLY);
	if (fd == -1) perror("open()");

	chdir("/tmp/foo");
	if (chroot("/tmp/foo") < 0)
		perror("chroot()");
	fexecve(fd, argv, environ);
	perror("fexecve()");
	return 0;
}

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 4 Feb 2009 09:47:26 +1300

On Wed, Feb 4, 2009 at 9:22 AM, Timo Sirainen <tss@iki.fi> wrote:
> On Wed, 2009-02-04 at 09:17 +1300, Michael Kerrisk wrote:
>> >> > And for ERRORS:
>> >> >
>> >> > ENOENT: /proc filesystem not available.
>> >> >
>> >> > ref: http://lkml.org/lkml/2006/12/27/140
>> >>
>> >> surely the error is ENOSYS (see the glibc source), which is already
>> >> documented in the man page?
>> >
>> > Well, what I did was:
>> >
>> > 1. open() an executable
>> > 2. chroot() to empty directory
>> > 3. drop root privileges
>> > 4. fexecve()
>> >
>> > And fexecve() return ENOENT. So I was assuming it's because there was
>> > no /proc in the empty dir..
>>
>> Can you provide a very simple test program?  In my tests, I am seeing
>> ENOSYS, as I would expect from reading the source.`
>
> Weird. I'm also getting ENOSYS now in my test program.

Thanks for the confirmation.

> 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.  (If
you have test program for this case, I'd be interested to see it, to
run a few experiemnts.)

Cheers,

Michael

> Test
> program:
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <string.h>
> #include <errno.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <fcntl.h>
>
> int main(void)
> {
>        extern char **environ;
>        char *argv[] = { "ls", NULL };
>        int fd = open("/bin/ls", O_RDONLY);
>        if (fd == -1) perror("open()");
>
>        chdir("/tmp/foo");
>        if (chroot("/tmp/foo") < 0)
>                perror("chroot()");
>        fexecve(fd, argv, environ);
>        perror("fexecve()");
>        return 0;
> }
>
>
>



-- 
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

Message #35 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Timo Sirainen <tss@iki.fi>

To: mtk.manpages@gmail.com

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Tue, 03 Feb 2009 16:07:42 -0500

[Message part 1 (text/plain, inline)]

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..

> (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.

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 4 Feb 2009 17:37:18 +1300

Hi Timo,

On Wed, Feb 4, 2009 at 10:07 AM, Timo Sirainen <tss@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

Message #45 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>, 514043@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 4 Feb 2009 17:49:03 +1300

tags 514043 fixed-upstream
thanks

> To prevent other people from wasting their time with fexecve(), I suggest
> adding something like this to the description:
>
> Linux implements fexecve() by executing the binary via proc filesystem,
> so /proc needs to be mounted and available during the fexecve() call.

Timo, I added a NOTES section with a sentence similar to the one you
gave above.  The change will be in 3.18.

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

Message #52 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Timo Sirainen <tss@iki.fi>

To: mtk.manpages@gmail.com

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Wed, 04 Feb 2009 18:28:17 -0500

[Message part 1 (text/plain, inline)]

On Wed, 2009-02-04 at 17:37 +1300, Michael Kerrisk wrote:
> > 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.

Oh, interesting. I hadn't thought of that. So I guess the ENOENT error
then means it couldn't satisfy all dynamic dependencies.

[signature.asc (application/pgp-signature, inline)]

Message #57 received at 514043@bugs.debian.org (full text, mbox, reply):

From: Michael Kerrisk <mtk.manpages@googlemail.com>

To: Timo Sirainen <tss@iki.fi>

Cc: 514043@bugs.debian.org

Subject: Re: Bug#514043: manpages-dev: fexecve() should mention it doesn't work inside chroot

Date: Thu, 5 Feb 2009 12:50:22 +1300

On Thu, Feb 5, 2009 at 12:28 PM, Timo Sirainen <tss@iki.fi> wrote:
> On Wed, 2009-02-04 at 17:37 +1300, Michael Kerrisk wrote:
>> > 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.
>
> Oh, interesting. I hadn't thought of that. So I guess the ENOENT error
> then means it couldn't satisfy all dynamic dependencies.

That is how I undestand it.

-- 
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

Message #62 received at 514043-close@bugs.debian.org (full text, mbox, reply):

From: Joey Schulze <joey@infodrom.org>

To: 514043-close@bugs.debian.org

Subject: Bug#514043: fixed in manpages 3.18-1

Date: Fri, 24 Apr 2009 16:17:58 +0000

Source: manpages
Source-Version: 3.18-1

We believe that the bug you reported is fixed in the latest version of
manpages, which is due to be installed in the Debian FTP archive:

manpages-dev_3.18-1_all.deb
  to pool/main/m/manpages/manpages-dev_3.18-1_all.deb
manpages_3.18-1.dsc
  to pool/main/m/manpages/manpages_3.18-1.dsc
manpages_3.18-1.tar.gz
  to pool/main/m/manpages/manpages_3.18-1.tar.gz
manpages_3.18-1_all.deb
  to pool/main/m/manpages/manpages_3.18-1_all.deb



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 514043@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Joey Schulze <joey@infodrom.org> (supplier of updated manpages package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 24 Apr 2009 18:01:15 +0200
Source: manpages
Binary: manpages manpages-dev
Architecture: source all
Version: 3.18-1
Distribution: unstable
Urgency: low
Maintainer: Martin Schulze <joey@debian.org>
Changed-By: Joey Schulze <joey@infodrom.org>
Description: 
 manpages   - Manual pages about using a GNU/Linux system
 manpages-dev - Manual pages about using GNU/Linux for development
Closes: 512709 514043
Changes: 
 manpages (3.18-1) unstable; urgency=low
 .
   * New upstream release
     . Correction of fexecve(3) (closes: Bug#514043)
     . Obsolete isalpha(3) (closes: Bug#512709)
   * Avoid distribution pthread pages that are currently also provided by
     glibc-doc:
     . pthread_kill_other_threads_np(3)
     . pthread_sigmask(3)
     . pthread_kill(3)
Checksums-Sha1: 
 9939cc003ab05d9f93c121e03d1a58066feffcea 723 manpages_3.18-1.dsc
 628a45d84dd670b10b0469f572302c2f325966d4 1613699 manpages_3.18-1.tar.gz
 122d371079df756eeedb9ac0731f0bf7b62f4b01 705904 manpages_3.18-1_all.deb
 7cddd27ee1f9e2381fccd001408e16b3b5ab1a6b 1541212 manpages-dev_3.18-1_all.deb
Checksums-Sha256: 
 1a21c7b10b8a0fa854978b4feec353dfdee0aac143d3957701e20c30f1ff7dcc 723 manpages_3.18-1.dsc
 0c5989ee31c2eb59851586fecd2a9bc351e8dbd25b20a9090e310095f1aecaa1 1613699 manpages_3.18-1.tar.gz
 022dfe4fdbb2b0289d51bf064891d6d520695bf22a2014c0d98accd66de4e62b 705904 manpages_3.18-1_all.deb
 db64848a6904d2116109d1c77a2e9bc81b7dbbd28682b97402fd38e0704425f3 1541212 manpages-dev_3.18-1_all.deb
Files: 
 3d9a3cdfdba761cd47629e77b24a6268 723 doc important manpages_3.18-1.dsc
 5f53d782ac4f8934c4819ae215b0c385 1613699 doc important manpages_3.18-1.tar.gz
 327ff6371590c9baac7de3af311262ab 705904 doc important manpages_3.18-1_all.deb
 d19aabebe8a1e69bbcab83428ec1d88d 1541212 doc optional manpages-dev_3.18-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iD8DBQFJ8eL4W5ql+IAeqTIRAtncAJ9GvZB5A9Z8IiwDcyviDgdPCuOKwwCdF1Mx
SFK7iAJ0zlTz/B6356Xw4O4=
=NF6e
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.