[lxc-devel] [PATCH 1/1] resolve lxcpath and rcfile arguments

Serge Hallyn serge.hallyn at ubuntu.com
Tue Nov 5 13:30:17 UTC 2013


Quoting Stéphane Graber (stgraber at ubuntu.com):
> On Mon, Nov 04, 2013 at 02:44:44PM -0600, Serge Hallyn wrote:
> > So we don't always have to give full paths.
> > 
> > realpath(x,NULL) mallocs memory, but these paths shouldn't get called
> > from the API so not freeing should be ok.
> > 
> 
> What's the reason behind this change?

Simply that as I test unprivileged lxc I'm having to do

	lxc-create -t ubuntu-cloud -P /home/serge/lxcbase -f /home/serge/lxc.conf -n a1 -- -r saucy
	lxc-start -P /home/serge/lxcbase -n a1
	lxc-stop -P /home/serge/lxcbase -n a1 -K

and it gets a bit old.  But maybe (in the fresh light of morning) I'm better
off adding a per-user lxc.conf file that specifies default lxcpath and
lxc.conf to use.

> Am I reading this right that this will only affect cases where -P is
> passed and that the default value won't be resolved?
> 
> In any case, I suspect this change is incomplete since we also support
> -P in some of the python tools which wouldn't be resolved, leading to
> lxc-info and others to fail to find the container (if for example
> /var/lib/lxc is a symlink to say /data/containers).
> 
> 
> > Signed-off-by: Serge Hallyn <serge.hallyn at ubuntu.com>
> > ---
> >  src/lxc/arguments.c   |  9 ++++++++-
> >  src/lxc/lxc_execute.c | 10 +++++++---
> >  src/lxc/lxc_start.c   |  9 +++++++++
> >  3 files changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/src/lxc/arguments.c b/src/lxc/arguments.c
> > index adcf8fe..65b2284 100644
> > --- a/src/lxc/arguments.c
> > +++ b/src/lxc/arguments.c
> > @@ -155,6 +155,7 @@ See the %s man page for further information.\n\n",
> >  static int lxc_arguments_lxcpath_add(struct lxc_arguments *args,
> >  				     const char *lxcpath)
> >  {
> > +	char *resolved_path = NULL;
> >  	if (args->lxcpath_additional != -1 &&
> >  	    args->lxcpath_cnt > args->lxcpath_additional) {
> >  		fprintf(stderr, "This command only accepts %d -P,--lxcpath arguments\n",
> > @@ -168,7 +169,13 @@ static int lxc_arguments_lxcpath_add(struct lxc_arguments *args,
> >  		lxc_error(args, "no memory");
> >  		return -ENOMEM;
> >  	}
> > -	args->lxcpath[args->lxcpath_cnt++] = lxcpath;
> > +	resolved_path = realpath(lxcpath, NULL);
> > +	if (!resolved_path) {
> > +		perror("realpath");
> > +		fprintf(stderr, "Error resolving lxcpath %s", lxcpath);
> > +		return -1;
> > +	}
> > +	args->lxcpath[args->lxcpath_cnt++] = resolved_path;
> >  	return 0;
> >  }
> >  
> > diff --git a/src/lxc/lxc_execute.c b/src/lxc/lxc_execute.c
> > index 6a54bf6..083b5db 100644
> > --- a/src/lxc/lxc_execute.c
> > +++ b/src/lxc/lxc_execute.c
> > @@ -105,9 +105,13 @@ int main(int argc, char *argv[])
> >  		return -1;
> >  
> >  	/* rcfile is specified in the cli option */
> > -	if (my_args.rcfile)
> > -		rcfile = (char *)my_args.rcfile;
> > -	else {
> > +	if (my_args.rcfile) {
> > +		rcfile = realpath((char *)my_args.rcfile, NULL);
> > +		if (!rcfile) {
> > +			SYSERROR("Failed to resolve file path: %s", my_args.rcfile);
> > +			return -1;
> > +		}
> > +	} else {
> >  		int rc;
> >  
> >  		rc = asprintf(&rcfile, "%s/%s/config", my_args.lxcpath[0], my_args.name);
> > diff --git a/src/lxc/lxc_start.c b/src/lxc/lxc_start.c
> > index add2542..7eea26a 100644
> > --- a/src/lxc/lxc_start.c
> > +++ b/src/lxc/lxc_start.c
> > @@ -173,6 +173,15 @@ int main(int argc, char *argv[])
> >  
> >  	const char *lxcpath = my_args.lxcpath[0];
> >  
> > +	if (my_args.rcfile) {
> > +		char *r = realpath(my_args.rcfile, NULL);
> > +		if (!r) {
> > +			SYSERROR("Failure resolving path: %s", my_args.rcfile);
> > +			exit(1);
> > +		}
> > +		my_args.rcfile = r;
> > +	}
> > +
> >  	/*
> >  	 * rcfile possibilities:
> >  	 * 1. rcfile from random path specified in cli option
> > -- 
> > 1.8.1.2
> > 
> > 
> > ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models. Explore
> > techniques for threading, error checking, porting, and tuning. Get the most 
> > from the latest Intel processors and coprocessors. See abstracts and register
> > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Lxc-devel mailing list
> > Lxc-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/lxc-devel
> 
> -- 
> Stéphane Graber
> Ubuntu developer
> http://www.ubuntu.com






More information about the lxc-devel mailing list