On Thu, Sep 05, 2013 at 02:47:25PM -0700, Eric W. Biederman wrote:
[..]
> >> An important detail to look at is mount propagation, especially on
> >> fedora. You need to make all of your mounts private to make certain
> >> mounts don't propogate out and possibly take some defensive measures
> >> to keep mounts or umounts from propogating in. Remount /proc
> >> and /sys should be enough to defend against that but it is worth
> >> thinking about.
> >
> > Hi Eric,
> >
> > I do make /sbin/kexec's mount namespace private recursively so that no
> > mount events are propagated in/out.
> >
> > + * make root private so that no mount event from previous
> > namespace
> > + * are propogated
> > + */
> > + ret = mount("", "/", "", MS_REC | MS_PRIVATE, "");
> > + if (ret == -1) {
> > + fprintf(stderr, "mount(MS_REC|MS_PRIVATE) failed:%s\n",
> > + strerror(errno));
> > + return -1;
> > + }
>
> That prevents transmission but my previous read of the code says you
> will still receive mount changes, for mount points the parent shares.
> Which are all of them in the world of systemd, last I heard.
Hi Eric,
I think I am not understanding something very basic. I am not sure what do
you mean by "still receive mount changes for mount points the parent shares".
I tried following.
- Open a terminal
- mkdir /tmp/kexec-proc
- mount -t proc none /tmp/kexec-proc
- Now open another terminal and launch a bash shell with separate mount
namespace
unshare -m bash
- In the new bash shell I can see that proc is mounted on /tmp/kexec-proc
- In the new bash shell, make / private recursively.
mount --make-rprivate /
- Now in original bash shell unmount /tmp/kexec-proc
- I go back to new bash and there /tmp/kexec-proc is still mounted. So
changes to original mount namespace did not reflect in this new one. I
am assuming same will happen when systemd does some changes to initial
mount namespace and they should not be visible in /sbin/kexec mount
namespace.
Looks like I am entirely missing the point you are making. Can you please
elaborate a bit.
Thanks
Vivek
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
