On Thu, Nov 14, 2013 at 05:44:40PM +0800, Chen Hanxiao wrote:
> -----Original Message-----
> From: Daniel P. Berrange [mailto:berrange@redhat.com]
> Sent: Wednesday, November 13, 2013 6:35 PM
> To: Chen Hanxiao
> Cc: libvir-list(a)redhat.com
> Subject: Re: [libvirt] [PATCH v2]lxc: don't mount dir if ownership couldn't
be
> known
>
> On Wed, Nov 13, 2013 at 04:51:43PM +0800, Chen Hanxiao wrote:
> > From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com>
> >
> > If we enable userns, we could bind mount
> > some dirs from host to guest, which don't belong to
> > the target mapped uid/gid.
> >
> > Such as we could bind mount root's dirs to guest.
> > What is worse, we could even modify root's files
> > in that bind dir inside container.
>
> I still can't see what the problem is from the description
> here. Please can you give a clear example of the config
> used and exactly what goes wrong.
>
1. enable user namespace
<idmap>
<uid start='0' target='1001' count='10'/>
<gid start='0' target='1001' count='10'/>
</idmap>
2. bind mount some dirs to container, which belongs to root or other users.
<filesystem type='mount' accessmode='passthrough'>
<source dir='/media/LXC1'/>
<target dir='/mnt'/>
</filesystem>
# ll /media/
...
drwxr-xr-x. 3 root root 4096 Nov 13 17:21 LXC1
...
3. start container
I used to encounter issues: inside container, we could modify files under /mnt
So I think inside user namespace, if we do not have a proper id mapping,
we should not bind mount it for containers, or at least set it as readonly.
FYI, I'm trying to reproduce the problem myself, but have discovered
that current kernels cause a regression which prevents libirt starting
any user namespace kernels - it fails mounting /proc and /dev/pts
What kernel version are you testing with ?
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|