On Tue, 11.03.14 14:14, Christoph Berg (m...@debian.org) wrote:
> Re: Michael Stapelberg 2014-03-08 <x6d2hwflle....@midna.zekjur.net>
> > The following patch works for me to make your newpid program work:
> >
> > --- i/newpid.c
> > +++ w/newpid.c
> > @@ -40,11 +40,9 @@ run (void *argv_void)
> > pid_t child;
> > pid_t pid;
> >
> > - if (umount ("/proc") != 0) {
> > - /* ignore errors here, /proc could be busy
> > - perror ("umount /proc");
> > + if (mount("none", "/proc", NULL, MS_PRIVATE|MS_REC, NULL) !=
> > - 0)
Please do not use MS_PRIVATE for this. This has the the result to
disconnect propagation both ways, which doesn't sound too bad, but
actually is. The reason is that this controls propagation for both mount
*and* umount. Hence any file system you inherited from the root
namespace will stay mounted forever in your detached namespace, and that
might be a problem for the admin since that way the device it is mounted
from is kept busy until forever. If you use MS_SLAVE however then any
umount from the host will still propagate into your namespace, and thus
no t keep things busy. Now, if you only care about /proc then this isn't
too bad as no block devices are mounted below /proc, but I would still
do it, since at least binfmt_misc is still mounted there...
MS_PRIVATE only makes sense on file systems you created entirely on your
own.
> Ok, that works, thanks! I only tried to remount / which didn't seem to
> have any effect.
>
> Unfortunately MS_PRIVATE and MS_REC are not defined in squeeze, so
> that fix won't work for chroots running on a systemd system, but
> that's something I should be able to work around.
They have been vailable in the kernel for a long long time. If you libc
doesn't expose them use something like this:
#ifndef MS_PRIVATE
#define MS_PRIVATE (1 << 18)
#endif
#ifndef MS_REC
#define MS_REC 16384
#endif
We use the same code in systemd.
Lennart
--
Lennart Poettering, Red Hat
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
