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

[Serge Hallyn]

Quoting KATOH Yasufumi (karma at jazz.email.ne.jp):
> 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

Thanks.  Sounds good then.  Do you mind re-sending your patch?