Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
Re: Lennart Poettering 2014-03-11 20140311134118.gc4...@tango.0pointer.de Please do not use MS_PRIVATE for this. This has the the result to Ok, thanks for the suggestion. 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 Yeah, I've done that now (with MS_SLAVE). Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
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)
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.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
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
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
Hi Christoph,
Christoph Berg m...@debian.org writes:
Pardon this question, but how do I do this mount --make-rprivate /
in C? I've tried stracing mount:
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)
- {
+ perror (remount proc private);
exit (1);
- */
}
if (mount (proc, /proc, proc, 0, NULL) != 0) {
I took this from
https://git.kernel.org/cgit/utils/util-linux/util-linux.git/tree/sys-utils/unshare.c#n182
--
Best regards,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
Re: Michael Stapelberg 2014-02-28 x6iorznpli@midna.zekjur.net
For the people affected by this, please open separate bugs against the
affected packages to get the software fixed which makes assumptions
about shared/private-ness that doesn’t necessarily hold. Thanks.
Pardon this question, but how do I do this mount --make-rprivate /
in C? I've tried stracing mount:
mount(/dev/mapper/Debian-root, /, none, MS_REC|MS_PRIVATE,
errors=remount-ro,discard) = 0
... but every combination of MS_REMOUNT MS_REC MS_PRIVATE I've tried
on / and /proc leaves me with a /proc in the main system that simply
doesn't have any pid dirs.
The program in question is newpid:
https://github.com/ChristophBerg/newpid/blob/master/newpid.c
... with an extra chunk before mount(proc):
if (mount (, /, , MS_REC|MS_PRIVATE, NULL) != 0) {
perror (mount /);
exit (1);
}
Am I supposed to parse the current mount flags etc from /proc/mounts
before doing that?
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
signature.asc
Description: Digital signature
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
On Fri, 28.02.14 06:51, Martin Pitt (mp...@debian.org) wrote: We turned the default from PRIVATE to SHARED on request of the container and security guys, since they want that if you mount something from the host into a subdir of the container, it should just appear there, because that's what most people would most likely expect. Well, but conversely what scripts/people expected before that script was that something that you run under unshare -m really actually did what it says on the tin, namely that it really *does* have its private mount name space. Now it doesn't, and mounts done in that unshared process affect the system outside of it. I. e. all such programs now have to be changed to do that mount --make-rprivate / dance. I have talked to Karel, he's thinking about adding --propagation=slave|shared|private|none to unshare -m now, with a default of slave. Please ping him on IRC or so, so that he sees that there is demand for that. With that change unshare -m should work for everybody the same. The kernel default for this is unlikely to change since they argue that it breaks compatbility, which I kinda agree with. In systemd however, we thought we'd better pick saner defaults. That has the same net effect though, changing the global default? systemd and the kernel shouldn't have two different defaults, otherwise we'll eternally have scripts and programs with different expectations. Well, we don't provide 100% compat anyway, just 99%. We are pretty sure that the shared default makes a lot of sense though and that apps that need their private setups need to be fixed anyway, so we took the liberty to switch here, better earlier than later. Of course, that worked for us quite well, since we already did this change 3y ago where people probably didn't assume things about unshare -m so much yet... 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
Bug#739593: [Pkg-systemd-maintainers] Bug#739593: Bug#739593: closed by Michael Stapelberg stapelb...@debian.org (Re: Bug#739593: systemd makes / shared by default)
Hey all, Lennart Poettering [2014-02-27 19:50 +0100]: Lennart, we are considering disabling the code in systemd which makes / shared by default so that we follow the kernel default. Hmm? Why would you do that? TBH I found it rather unexpected from systemd to suddenly change that kernel default, as it has worked the other way for years. Now we are between a rock and a hard place: Installing systemd breaks existing stuff that relies on unshared name spaces being private, and patching it back out breaks applications which rely on the new systemd behaviour. We turned the default from PRIVATE to SHARED on request of the container and security guys, since they want that if you mount something from the host into a subdir of the container, it should just appear there, because that's what most people would most likely expect. Well, but conversely what scripts/people expected before that script was that something that you run under unshare -m really actually did what it says on the tin, namely that it really *does* have its private mount name space. Now it doesn't, and mounts done in that unshared process affect the system outside of it. I. e. all such programs now have to be changed to do that mount --make-rprivate / dance. The kernel default for this is unlikely to change since they argue that it breaks compatbility, which I kinda agree with. In systemd however, we thought we'd better pick saner defaults. That has the same net effect though, changing the global default? systemd and the kernel shouldn't have two different defaults, otherwise we'll eternally have scripts and programs with different expectations. TL;DR: fix the individual processes locally to disassociate their namespaces. Don't tape over it by making all of them disassociate by default, breaking those which do not want to disassociate. Because after disassociation there is no way back. I agree that due to this symmetric behaviour of unsharing (which is really counterintuitive and broken at first sight, but I guess it's technically difficult to implement in a proper host/guest fashion) we really shouldn't patch that back in Debian, and just live with the fallout (and find and fix it over time), as there is no way back as you explained. Perhaps as a mitigation /usr/bin/unshare could be fixed to imply making the unshared namespace private, so that this behaviour continues as it does before. And of course the kernel should then also default to the new behaviour, otherwise we have an eternal inconsistency there and a default which nobody actually uses. Thanks for your explanations! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
