On Tue, Oct 20, 2015 at 03:30:19PM +0000, Serge Hallyn wrote:
> Quoting Christian Brauner (christianvanbrau...@gmail.com):
> > The mount_entry_overlay_dirs() and mount_entry_aufs_dirs() functions create
> > workdirs and upperdirs for overlay and aufs lxc.mount.entry entries. They 
> > try
> > to make sure that the workdirs and upperdirs can only be created under the
> > containerdir (e.g. /path/to/the/container/CONTAINERNAME). In order to do 
> > this
> > the right hand side of
> > 
> >                 if ((strncmp(upperdir, lxcpath, dirlen) == 0) && 
> > (strncmp(upperdir, rootfs->path, rootfslen) != 0))
> > 
> > was thought to check if the rootfs->path is not present in the workdir and
> > upperdir mount options. But the current check is bogus since it will be
> > trivially true whenever the container is a block-dev or overlay or aufs 
> > backed
> > since the rootfs->path will then have a form like e.g.
> > 
> >         overlayfs:/some/path:/some/other/path
> > 
> > This patch adds the function ovl_get_rootfs_dir() which parses rootfs->path 
> > by
> > searching backwards for the first occurrence of the delimiter pair ":/". We 
> > do
> > not simply search for ":" since it might be used in path names. If ":/" is 
> > not
> > found we assume the container is directory backed and simply return
> > strdup(rootfs->path).
> > 
> > Signed-off-by: Christian Brauner <christianvanbrau...@gmail.com>
> > ---
> >  src/lxc/conf.c | 115 
> > ++++++++++++++++++++++++++++++++++++++++++++-------------
> >  1 file changed, 90 insertions(+), 25 deletions(-)
> > 
> > diff --git a/src/lxc/conf.c b/src/lxc/conf.c
> > index 16a62f8..301fe50 100644
> > --- a/src/lxc/conf.c
> > +++ b/src/lxc/conf.c
> > @@ -1815,12 +1815,65 @@ static void cull_mntent_opt(struct mntent *mntent)
> >     }
> >  }
> >  
> > +static char *ovl_get_rootfs_dir(const char *rootfs_path, size_t *rootfslen)
> > +{
> > +   char *end = NULL;
> > +   char *s1 = NULL;
> > +   char *s2 = NULL;
> > +   char *rootfsdir = NULL;
> > +   char *tmp = NULL;
> > +   size_t len = 0;
> > +   size_t slen = 0;
> > +
> > +   if (!rootfs_path || !rootfslen )
> > +           return NULL;
> > +
> > +   *rootfslen = 0;
> > +
> > +   s1 = strdup(rootfs_path);
> > +   if (!s1)
> > +           return NULL;
> > +
> > +   s2 = malloc(strlen(rootfs_path) + 1);
> > +   if (!s2) {
> > +           free(s1);
> > +           return NULL;
> > +   }
> > +   end = stpcpy(s2, rootfs_path);
> > +
> > +   /* If we find :/ in rootfs_path it means we either have a block-dev or
> > +    * overlay or aufs container. */
> > +   while ((tmp = strrchr(s1, ':'))) {
> > +           len = strlen(tmp);
> > +           *rootfslen += len;
> 
> If it is "overlay:/some/rootfs:/some/delta0", you will find the
> delta0 and return it as rootfsdir?
> 
> (or am i misreading?)
Nope, I thought that in the case where the /some/rootfs refers to another
containers rootfs it doesn't make sense to check against that path since this is
covered by the left hand side of the check further down. But in the case of
purely overlay-backed container it doesn't make sense... I'll rewrite that
part. Are there any more special cases apart from aufs and overlay. We have

blockdev:/some/path

overlayfs:/some/path:/some/delta0
aufs:/some/path:/some/delta0

Any more?

> 
> > +           if (strncmp(tmp, ":/", 2) == 0) {
> > +                   rootfsdir = strdup(end - *rootfslen + 1);
> > +                   break;
> > +           } else {
> > +                   slen = strlen(s1);
> > +                   s1[slen - len] = '\0';
> > +           }
> > +   }
> > +   free(s1);
> > +
> > +   if (!*rootfslen && !tmp)
> > +           rootfsdir = s2;
> > +   else
> > +           free(s2);
> > +
> > +   if (rootfsdir)
> > +           *rootfslen = strlen(rootfsdir);
> > +
> > +   return rootfsdir;
> > +}
> _______________________________________________
> lxc-devel mailing list
> lxc-devel@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

Attachment: signature.asc
Description: PGP signature

_______________________________________________
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel

Reply via email to