[lxc-devel] [PATCH] aufs: Support unprivileged clone, mount

[KATOH Yasufumi]

Hi, sorry for my late reply.

>>> On Thu, 7 May 2015 13:22:51 +0000
    in message   "Re: [lxc-devel] [PATCH] aufs: Support unprivileged clone, mount"
                  Serge Hallyn-san wrote:

> Quoting KATOH Yasufumi (karma at jazz.email.ne.jp):
> > >>> On Thu, 30 Apr 2015 14:02:55 +0000
> >     in message   "Re: [lxc-devel] [PATCH] aufs: Support unprivileged clone, mount"
> >                   Serge Hallyn-san wrote:
> > 
> > > Quoting KATOH Yasufumi (karma at jazz.email.ne.jp):
> > > > Current aufs supports FS_USERNS_MOUNT by using allow_userns module
> > > > parameter. It allows root in userns to mount aufs.
> > > > 
> > > > This patch allows an unprivileged container to use aufs.
> > > > 
> > > > Signed-off-by: KATOH Yasufumi <karma at jazz.email.ne.jp>
> > > > ---
> > > >  src/lxc/bdev.c | 65 +++++++++++++++++++++++++++++++---------------------------
> > > >  1 file changed, 35 insertions(+), 30 deletions(-)
> > > > 
> > > > diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
> > > > index cf7c043..eb516c8 100644
> > > > --- a/src/lxc/bdev.c
> > > > +++ b/src/lxc/bdev.c
> > > > @@ -2552,12 +2552,12 @@ static int aufs_detect(const char *path)
> > > >  //
> > > >  static int aufs_mount(struct bdev *bdev)
> > > >  {
> > > > -	char *options, *dup, *lower, *upper, *rundir;
> > > > +	char *options, *dup, *lower, *upper;
> > > >  	int len;
> > > >  	unsigned long mntflags;
> > > >  	char *mntdata;
> > > > -	char *runpath;
> > > >  	int ret;
> > > > +	const char *xinopath = "/dev/shm/aufs.xino";
> > 
> > > So who will create this directory?  What are its permissions?
> > > Does aufs somehow autocreate that in such a way that anyone
> > > can create files (and immediately delete) files there?
> > 
> > Thanks for your reply.
> > 
> > '/dev/shm' may not always exists, or may not always be 1777, so this
> > code may cause a problem on such a system.

> /dev/shm yes, but what about /dev/shm/aufs.xino itself.

> Wait - is /dev/shm/aufs.xino a directory under which files will be
> created (and immediately deleted), or /dev/shm/aufs.xino itself going
> to be created and immediately unlinked?  If the latter then what I'm
> asking doesn't matter.

xino is a file that is used as inode number bitmap and translation
table.

> > But many software expect the existent of /dev/shm for shared memory
> > area. So many distributions have /dev/shm. And it is usually mounted
> > as tmpfs, and its permission is usually set 1777. For example,
> > 
> >   - systemd creates /dev/shm, and mount as tmpfs, and set mode=1777 at
> >     boot time.
> >   - Ubuntu Trusty, Debian wheezy has /dev/shm as the link to /run/shm
> >     (mode=1777)
> > 
> > xino file is created per aufs branch automatically.

> Automatically at boot, or at the first mount time?  I.e. whose credentials
> are used to created it.

It is created at the mount time, but it is created internally, so we
can't find it.

> > We can specify the
> > same xino to multiple aufs mounts. After a aufs priv container is
> > started, I could run a unpriv aufs container at the same time.
> > 
> > So I think that it is not a problem in many cases.
> > 
> > Does that answer your question?

> no, though I may just be being dense.  But can you please reboot
> such a system, start a aufs-backed root-owned container, then
> show the result of 'ls -ld /dev/shm/aufs.xino' and
> 'ls -l /dev/shm/aufs.xino' ?

I questioned aufs author about the xino file. It is created and
unlinked internally per mount, and not shared among multiple aufs
mounts.

  http://sourceforge.net/p/aufs/mailman/message/34121720/

Thanks,
KATOH Yasufumi