Paul Tagliamonte wrote: > Once I was able to get a browser open, I found out olasd had researched > and found a commit[1] that seems to mark this as systemd's decision that > the kernel is wrong(?)
> [1]: > http://cgit.freedesktop.org/systemd/systemd/commit/?id=b3ac5f8cb98757416d8660023d6564a7c411f0a0 I'm not sure I'd interpret that commit message as endorsing the behavior of allowing containers to unmount host filesystems. As I understand it, the intent of systemd's use of shared mounts was to ensure that new mounts/umounts in the *host* are propagated to the *guest* (which doesn't seem like an unreasonable default for containers that share a root filesystem), not necessarily the other way around. This case may simply need further evaluation upstream. Furthermore, if you're sharing filesystems with a container, there are many other ways that container can potentially hose the host filesystems if not prevented from doing so, such as deleting files *on* those filesystems rather than unmounting them. (That's not a theoretical concern, as anyone who has ever 'rm -rf'ed a chroot containing a bind mount understands quite well.) Any potential fix would need to take that into account as well. In any case, I'd suggest starting this conversation with upstream, explaining the observed behavior and asking for further clarifying details on the intended behavior. I also believe that preemptively CCing the tech-ctte on bugs like this is a mistake, as it undermines the normal assumption that maintainers of different packages are capable of normal cooperation. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
