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?!
Created attachment 19253 [details] test program to reproduce problem
Reply-To: akpm@linux-foundation.org (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@bugzilla.kernel.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@kernel-bugs.osdl.org > ReportedBy: robert.rex@exasol.com > > > 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.
Reply-To: sukadev@linux.vnet.ibm.com Andrew Morton [akpm@linux-foundation.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@bugzilla.kernel.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@kernel-bugs.osdl.org | > ReportedBy: robert.rex@exasol.com | > | > | > 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
Andrew Morton <akpm@linux-foundation.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@bugzilla.kernel.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@kernel-bugs.osdl.org >> ReportedBy: robert.rex@exasol.com >> >> >> 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
ebiederm@xmission.com wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=12199 > [...] > 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 Thanks for your analysis! That sounds reasonable (I didn't recognize the use of CLONE_NEWNS - just pasting from the examples ;-) - but I needed it to mount a proc filesystem in the new PID namespace while using the other one "outside"). So, I may not count on the /proc/{PID}/exe link anymore in such cases as far as I see. Robert
robert.rex@exasol.com writes: > Thanks for your analysis! That sounds reasonable (I didn't recognize the use > of > CLONE_NEWNS - just pasting from the examples ;-) - but I needed it to mount a > proc filesystem in the new PID namespace while using the other one > "outside"). So, I may not count on the /proc/{PID}/exe link anymore in such > cases as far as I see. Just setup the mount namespace instead of setting up a chroot and all will be well. Eric