[lxc-devel] [PATCH v3] Parse rootfs->path

Christian Brauner christianvanbrauner at gmail.com
Tue Oct 20 16:08:16 UTC 2015


On Tue, Oct 20, 2015 at 03:30:19PM +0000, Serge Hallyn wrote:
> Quoting Christian Brauner (christianvanbrauner at 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 <christianvanbrauner at 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 at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20151020/d43f5b5a/attachment.sig>


More information about the lxc-devel mailing list