Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx >> ReportedBy: robert.rex@xxxxxxxxxx >> >> >> 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 _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers