[Lxc-users] read only rootfs

[C Anthony Risinger]

On Mon, Jul 18, 2011 at 7:36 AM, Serge E. Hallyn <serge at hallyn.com> wrote:
> Quoting C Anthony Risinger (anthony at xtfx.me):
>> On Jul 15, 2011 12:01 PM, "Michael H. Warfield" <mhw at wittsend.com> wrote:
>> >
>> > Unfortunately, I also still find that if there's a -o remount,ro in the
>> > halt/reboot script, it still sets /dev/pts to ro and that still
>> > propagates to the host and to the other containers triggering random
>> > acts of terrorism like "unable to create pty/0" in the containers and
>> > inability to start new containers in the host.  Not sure if we can apply
>> > a bind to that or not.
>>
>> Doesn't `-o newinstance` mount option to devpts mounts prevent this?  It
>
> I haven't looked further than reading Michael's email, but a plausible
> sequence is that (a) the container's rootfs is just a bind mount from the
> parent's,

not a good idea if so :-)

> (b) the mount -o remount,ro is not being done with 'bind' and so
> affects the fs, not the mount (as helpfully pointed out a few weeks ago on
> irc by dhansen),

ahhh, i did not know it behaved like that ... hrmm.  i knew you needed
`-o bind` but i never even considered acting on the bind would *ever*
affect the original mountpoint ... interesting, thanks.

> and so (c) the fs on which the host's /var/lib/lxc/<container>/rootfs
> is mounted gets recursively mounted ro, and the host's /dev/pts is under
> that.

per your other comment, i didn't realize some distros --make-[r]shared
/ by default (or are mount points themselves shared by default?  how
to do that?) ... thats probably why i don't see this behavior; all my
machines are Archlinux and we probably aren't changing the upstream
defaults.

>> should privatize the devices for each ... its best to mount host this way
>> too -- then set symlink for each:
>>
>> /dev/ptmx -> /dev/pts/ptmx
>>
>> > The kernel should also prohibit, totally, the propagation of remount
>> > options from inside a container to the outer host or to other
>> > containers.  That is tantamount to a security vulnerability and clearly
>> > a violation of container isolation.
>>
>> But not all use cases are system containers, eg 100% isolated.  Isn't a
>> slave mount enough to prevent this?  I'd have to check but I *thought* bind
>> mounts only responded to the `ro` flag ... and the new mount NS I'd think
>> would play a role too ... not sure details offhand.
>
> See '(b)' above.  You're sort of mixing mounts propagation with bind mounts
> subtleties.  Your second sentence in that paragraph is 100% correct.

yes i see that.  pretty much all i know was from hours of trial an
error understanding the semantics ... definitely a few gotchas in
there it would seem.  however, while i could *maybe* see the rootfs
being an unconditional slave, i would NOT want to see any lxc
default/enforcement preventing container -> host propagation on a
globally recursive scale.  im of the opinion that the implementor
should decide the best tactic ... especially in light of the fact the
one distro may not even have the same problems as say
ubutnu/fedora/etc because they keep mount points private by default.

>The third is non sequitur :)

beh :-) fair enough.  i've been known to ramble on ... slowly
degrading toward incohesive mumblings of interwoven thoughts in "real"
life, so i suppose this is the digital manifestation of these
tendencies ... <continues incoherently ...>

C Anthony