[lxc-devel] The view of bind-mounts from inside lxc containers

Stéphane Graber stgraber at ubuntu.com
Mon Nov 5 05:00:12 UTC 2018


On Sun, Nov 04, 2018 at 03:48:16PM +0200, Eytan Heidingsfeld wrote:
> Hello,
> I know this isn't lxc-specific but it is happening to me when using lxc.
> I'm using kubernetes/docker style bind-mounting of resolv.conf from the
> host into the rootfs of the container to ensure it stays up to date
> (instead of overriding the file manually on start or setting the parameters
> manually).
> 
> The problem is that inside the lxc container /proc/mounts has line like:
> /dev/sda1 /etc/resolv.conf from the bind mount and this causes some of the
> init/halt scripts to try and access /dev/sda1 and fail.
> 
> I know this is not a security concern as the container is running
> unprivileged and doesn't have access to the root or it's devices, but it
> does cause some annoying errors.
> 
> Does anyone have any similar use-cases of bind-mounts showing up in
> /proc/mounts and have any good solutions?
> 
> I was looking at lxcfs and thinking maybe to add code to handle this there,
> any thoughts?
> 
> Thanks,
> Eytan

In general this tends to show buggy software more than anything else,
bind-mounts are a thing and they do behave the exact same way outside of
containers (though the block device is certainly more likely to exist in
such case).

Software that expects the source field in the mount table to resolve to
a valid path to a block device is just wrong, this will fail in
containers, will fail in chroots and will fail with filesystems which
use a virtual source (like ZFS that shows <pool>/<dataset> rather than a
/dev path).


I don't think lxcfs should do anything in this case nor could it do a
good job at it anyway. That second part is because /proc/mounts is
effectively deprecated, all software these days should look at
/proc/self/mountinfo instead which will provide the same information but
also provide much more useful information on top of that
(including better handling of bind-mounts).

/proc/self is a symlink to the calling process and so a
/proc/<PID>/mountinfo exists for every process. If we wanted to start
masking that with lxcfs, we'd need to mask the entirety of /proc, making
every single /proc access slower in the process.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20181105/e4767de5/attachment.sig>


More information about the lxc-devel mailing list