Re: [Bugme-new] [Bug 12199] New: /proc/1/exe entry of PID namespace init process links to wrong executable

Re: [Bugme-new] [Bug 12199] New: /proc/1/exe entry of PID namespace init process links to wrong executable

[Andrew Morton]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Thu, 11 Dec 2008 08:16:55 -0800 (PST) bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=12199
> 
>            Summary: /proc/1/exe entry of PID namespace init process links to
>                     wrong executable
>            Product: Process Management
>            Version: 2.5
>      KernelVersion: 2.6.27.8
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: low
>           Priority: P1
>          Component: Other
>         AssignedTo: process_other-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
>         ReportedBy: robert.rex-GD4dBWQXeU/QT0dZR+AlfA@public.gmane.org
> 
> 
> Latest working kernel version:
> 
> None known.
> 
> Earliest failing kernel version:
> 
> 2.6.25.4, 2.6.27.4 and 2.6.27.8 show this behaviour, but I assume that it
> exists since 2.6.24 with the introduction of PID namespaces.
> 
> Distribution: CentOS 5.1
> 
> Hardware Environment: x86-64
> 
> Software Environment: (see attached test program)
> 
> Problem Description:
> 
> The /proc/1/exe entry of a new PID namespace does not link to the expected
> binary if it was started within a chroot. All other processes in this namespace
> link to the expected path.
> 
> Steps to reproduce: (see attached test program)
> 
> 1) chroot() into an appropriate directory.
> 2) Create a process, which clone()s a thread in a new PID namespace with
> CLONE_NEWPID.
> 3) Mount /proc from within this new namespace.
> 3) Read the /proc/1/exe link from within this new namespace. It points to the
> "real" binary, not the (expected) link that is valid in this chroot.
> 
> The attached program executes steps 2, 3 and 4 and does a "/bin/ls -la /proc/1
> /proc/2" in the new namespace. The output below was collected with the
> following commands:
> 
> 1) mkdir /tmp/target
> 2) mount /dev/sda1 /tmp/target (/dev/sda1 is also mounted on /)
> 3) chroot /tmp/target
> 4) ./pid_namespace_chroot
> 
> ---------------
> /proc/1:
> [...]
> lrwxrwxrwx   1 root root 0 Dec 11 16:18 exe ->
> /tmp/target/root/pid_namespace_chroot
> [...]
> lrwxrwxrwx   1 root root 0 Dec 11 16:18 root -> /
> [...]
> 
> /proc/2:
> [...]
> lrwxrwxrwx   1 root root 0 Dec 11 16:18 exe -> /bin/ls
> [...]
> lrwxrwxrwx   1 root root 0 Dec 11 16:18 root -> /
> [...]
> ---------------
> 
> Hopefully, I do not miss a point, but I assume that this is not intended?!
> 

Thanks.

There's a test program attached to the bugzilla report.

Re: [Bugme-new] [Bug 12199] New: /proc/1/exe entry of PID namespace init process links to wrong executable

[Sukadev Bhattiprolu]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Andrew Morton [akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org] wrote:
| 
| (switched to email.  Please respond via emailed reply-to-all, not via the
| bugzilla web interface).
| 
| On Thu, 11 Dec 2008 08:16:55 -0800 (PST) bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
| 
| > http://bugzilla.kernel.org/show_bug.cgi?id=12199
| > 
| >            Summary: /proc/1/exe entry of PID namespace init process links to
| >                     wrong executable
| >            Product: Process Management
| >            Version: 2.5
| >      KernelVersion: 2.6.27.8
| >           Platform: All
| >         OS/Version: Linux
| >               Tree: Mainline
| >             Status: NEW
| >           Severity: low
| >           Priority: P1
| >          Component: Other
| >         AssignedTo: process_other-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
| >         ReportedBy: robert.rex-GD4dBWQXeU/QT0dZR+AlfA@public.gmane.org
| > 
| > 
| > Latest working kernel version:
| > 
| > None known.
| > 
| > Earliest failing kernel version:
| > 
| > 2.6.25.4, 2.6.27.4 and 2.6.27.8 show this behaviour, but I assume that it
| > exists since 2.6.24 with the introduction of PID namespaces.

Hmm. I am able to repro the behavior with attached test case and with
CLONE_NEWPID removed. Ran this in a chroot shell and it shows complete
path. I tried on Ubuntu 8.04 (2.6.22-15, which has no pid namespace
support).

	$ mount /dev/sda3 /tmp/target
	$ chroot /tmp/target
	$ ./pid_namespace_chroot2
	/proc/self/exe is /tmp/target/tmp/pid_namespace_chroot2

set_mm_exe_file() call from flush_old_exec() sets 'mm->exe_file' to
'linux_bprm.file' and proc_exe_link() picks it up from there. 

Could this be related how linux_bprm.file is populated after chroot ?
I have not traced that yet.

Sukadev

[-- Attachment #2: pid_namespace_chroot2.c --]
[-- Type: text/x-csrc, Size: 909 bytes --]

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>

#define CLONE_NEWNS     0x00020000
#define CLONE_NEWPID    0x20000000

/** Compile with "gcc -o pid_namespace_chroot2 pid_namespace_chroot2.c" */

int do_child(void)
{
	int status;
	char buf[256];

	if (mount("none", "/proc", "proc", 0, NULL)) {
		perror("mount");
		return 1;
	}

	if (readlink("/proc/self/exe", buf, sizeof(buf)) < 0) {
		perror("READLINK");
		return 1;
	}
	printf("/proc/self/exe is %s\n", buf);

	if (umount("/proc")) {
		perror("umount");
		return 1;
	}


	return 0;
}

int main(void)
{
	int status, pid;
	void *stack = malloc(getpagesize());

	if (!stack) {
		perror("malloc");
		return 1;
	}

	pid = clone(do_child, stack + getpagesize(), CLONE_NEWNS, NULL);
	if (pid == -1) {
		perror("clone");
		return 1;
	}

	if (waitpid(pid, &status, __WALL) < 0) {
		perror("waitpid");
		return 1;
	}

	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 206 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers

Re: [Bugme-new] [Bug 12199] New: /proc/1/exe entry of PID namespace init process links to wrong executable

[Eric W. Biederman]

Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org> writes:

> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Thu, 11 Dec 2008 08:16:55 -0800 (PST) bugme-daemon-590EEB7GvNiWaY/ihj7yzEB+6BGkLq7r@public.gmane.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=12199
>> 
>>            Summary: /proc/1/exe entry of PID namespace init process links to
>>                     wrong executable
>>            Product: Process Management
>>            Version: 2.5
>>      KernelVersion: 2.6.27.8
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: low
>>           Priority: P1
>>          Component: Other
>>         AssignedTo: process_other-ztI5WcYan/vQLgFONoPN62D2FQJk+8+b@public.gmane.org
>>         ReportedBy: robert.rex-GD4dBWQXeU/QT0dZR+AlfA@public.gmane.org
>> 
>> 
>> Latest working kernel version:
>> 
>> None known.
>> 
>> Earliest failing kernel version:
>> 
>> 2.6.25.4, 2.6.27.4 and 2.6.27.8 show this behaviour, but I assume that it
>> exists since 2.6.24 with the introduction of PID namespaces.
>> 
>> Distribution: CentOS 5.1
>> 
>> Hardware Environment: x86-64
>> 
>> Software Environment: (see attached test program)
>> 
>> Problem Description:
>> 
>> The /proc/1/exe entry of a new PID namespace does not link to the expected
>> binary if it was started within a chroot. All other processes in this
> namespace
>> link to the expected path.
>> 
>> Steps to reproduce: (see attached test program)
>> 
>> 1) chroot() into an appropriate directory.
>> 2) Create a process, which clone()s a thread in a new PID namespace with
>> CLONE_NEWPID.
>> 3) Mount /proc from within this new namespace.
>> 3) Read the /proc/1/exe link from within this new namespace. It points to the
>> "real" binary, not the (expected) link that is valid in this chroot.
>> 
>> The attached program executes steps 2, 3 and 4 and does a "/bin/ls -la /proc/1
>> /proc/2" in the new namespace. The output below was collected with the
>> following commands:
>> 
>> 1) mkdir /tmp/target
>> 2) mount /dev/sda1 /tmp/target (/dev/sda1 is also mounted on /)
>> 3) chroot /tmp/target
>> 4) ./pid_namespace_chroot
>> 
>> ---------------
>> /proc/1:
>> [...]
>> lrwxrwxrwx   1 root root 0 Dec 11 16:18 exe ->
>> /tmp/target/root/pid_namespace_chroot
>> [...]
>> lrwxrwxrwx   1 root root 0 Dec 11 16:18 root -> /
>> [...]
>> 
>> /proc/2:
>> [...]
>> lrwxrwxrwx   1 root root 0 Dec 11 16:18 exe -> /bin/ls
>> [...]
>> lrwxrwxrwx   1 root root 0 Dec 11 16:18 root -> /
>> [...]
>> ---------------
>> 
>> Hopefully, I do not miss a point, but I assume that this is not intended?!
>> 
>
> Thanks.
>
> There's a test program attached to the bugzilla report.

This behavior is reproducible.

The code just calls d_path with resolves things against current->fs->root.
Which should be the caller.

So I see no apparent reason for this behavior.

Oh.  I see.

You specified NEWNS  in your clone flags, creating a new mount namespace
as well.

Your executable came from a different mount namespace and thus has a different
set of mounts.  Which defeats the logic in d_path to honor current->fs->root
because your executable came from a different universe.

No bugs here just weird corner cases with the mount namespace.

Eric