New: /proc/1/exe entry of PID namespace init process links to wrong executable

Bugme-new Andrew Morton 3 participants 3 messages Dec 11, 2008 – Dec 12, 2008 3 messages not in the archive

Share & tools

A message that is not in the archive (sent off-list or not yet received): [email protected]/

A message that is not in the archive (sent off-list or not yet received): bug-12199-10286-V0hAGp6uBxO456/isadD/[email protected]/

Andrew Morton

author

2008-12-11 17:14 UTC #2 lore raw

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

Quoted 74 lines · On Thu, 11 Dec 2008 08:16:55 -0800 (PST)…

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/[email protected]
ReportedBy: robert.rex-GD4dBWQXeU/[email protected]
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 -> /
[...]
---------------

Quoted 2 lines

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.

A message that is not in the archive (sent off-list or not yet received): 20081211091430.ea3d434d.akpm-de/[email protected]

Sukadev Bhattiprolu

2008-12-12 01:42 UTC #4 lore raw

Andrew Morton [akpm-de/[email protected]] 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/[email protected] 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/[email protected]
| >         ReportedBy: robert.rex-GD4dBWQXeU/[email protected]
| > 
| > 
| > 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

#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;
}

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

Eric W. Biederman

2008-12-12 01:48 UTC #5 lore raw

In reply to a message not in the archive

Quoted 80 lines · Andrew Morton

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
Quoted 29 lines · On Thu, 11 Dec 2008 08:16:55 -0800 (PST)…
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/[email protected]
ReportedBy: robert.rex-GD4dBWQXeU/[email protected]
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
Quoted 8 lines
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
Quoted 37 lines
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 -> /
[...]
---------------

Quoted 6 lines

Quoted 2 lines
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