[lxc-devel] [PATCH 4/4] uniformly nullify std fds

Tycho Andersen tycho.andersen at canonical.com
Tue Jun 9 11:48:52 UTC 2015


On Tue, Jun 09, 2015 at 11:48:05AM +0200, Robert Vogelgesang wrote:
> Hi,
> 
> On Mon, Jun 08, 2015 at 07:59:54PM -0600, Tycho Andersen wrote:
> > In various places throughout the code, we want to "nullify" the std fds,
> > opening them to /dev/null or zero or so. Instead, let's unify this code and
> > do it in such a way that Coverity (probably) won't complain.
> > 
> > Reported-by: Coverity
> > Signed-off-by: Tycho Andersen <tycho.andersen at canonical.com>
> > ---
> >  src/lxc/bdev.c         |  8 ++------
> >  src/lxc/lxccontainer.c | 19 ++++++-------------
> >  src/lxc/monitor.c      |  8 ++------
> >  src/lxc/start.c        | 10 ++--------
> >  src/lxc/utils.c        | 22 ++++++++++++++++++++++
> >  src/lxc/utils.h        |  1 +
> >  6 files changed, 35 insertions(+), 33 deletions(-)
> > 
> > diff --git a/src/lxc/bdev.c b/src/lxc/bdev.c
> > index 53465b1..520652c 100644
> > --- a/src/lxc/bdev.c
> > +++ b/src/lxc/bdev.c
> > @@ -224,12 +224,8 @@ static int do_mkfs(const char *path, const char *fstype)
> >  
> >  	// If the file is not a block device, we don't want mkfs to ask
> >  	// us about whether to proceed.
> > -	close(0);
> > -	close(1);
> > -	close(2);
> > -	open("/dev/zero", O_RDONLY);
> > -	open("/dev/null", O_RDWR);
> > -	open("/dev/null", O_RDWR);
> > +	if (null_stdfds() < 0)
> > +		exit(1);
> >  	execlp("mkfs", "mkfs", "-t", fstype, path, NULL);
> >  	exit(1);
> >  }
> > diff --git a/src/lxc/lxccontainer.c b/src/lxc/lxccontainer.c
> > index 445cc22..18fceeb 100644
> > --- a/src/lxc/lxccontainer.c
> > +++ b/src/lxc/lxccontainer.c
> > @@ -722,12 +722,10 @@ static bool do_lxcapi_start(struct lxc_container *c, int useinit, char * const a
> >  			return false;
> >  		}
> >  		lxc_check_inherited(conf, true, -1);
> > -		close(0);
> > -		close(1);
> > -		close(2);
> > -		open("/dev/zero", O_RDONLY);
> > -		open("/dev/null", O_RDWR);
> > -		open("/dev/null", O_RDWR);
> > +		if (null_stdfds() < 0) {
> > +			ERROR("failed to close fds");
> > +			return false;
> > +		}
> >  		setsid();
> >  	} else {
> >  		if (!am_single_threaded()) {
> > @@ -978,13 +976,8 @@ static bool create_run_template(struct lxc_container *c, char *tpath, bool quiet
> >  		char **newargv;
> >  		struct lxc_conf *conf = c->lxc_conf;
> >  
> > -		if (quiet) {
> > -			close(0);
> > -			close(1);
> > -			close(2);
> > -			open("/dev/zero", O_RDONLY);
> > -			open("/dev/null", O_RDWR);
> > -			open("/dev/null", O_RDWR);
> > +		if (quiet && null_stdfds() < 0) {
> > +			exit(1);
> 
> Here, maybe a comment should be added to say that "quiet" means we
> should close the fds by calling null_stdfds(), and not the other way
> around, that we should exit if null_stdfds() fails.

Alternatively I can nest the ifs, but doesn't the order of the
arguments in the && imply this?

> >  		}
> >  
> >  		src = c->lxc_conf->rootfs.path;
> > diff --git a/src/lxc/monitor.c b/src/lxc/monitor.c
> > index 0e56f75..144b16e 100644
> > --- a/src/lxc/monitor.c
> > +++ b/src/lxc/monitor.c
> > @@ -329,12 +329,8 @@ int lxc_monitord_spawn(const char *lxcpath)
> >  		exit(EXIT_FAILURE);
> >  	}
> >  	lxc_check_inherited(NULL, true, pipefd[1]);
> > -	close(0);
> > -	close(1);
> > -	close(2);
> > -	open("/dev/null", O_RDONLY);
> > -	open("/dev/null", O_RDWR);
> > -	open("/dev/null", O_RDWR);
> > +	if (null_stdfds() < 0)
> > +		exit(EXIT_FAILURE);
> >  	close(pipefd[0]);
> >  	sprintf(pipefd_str, "%d", pipefd[1]);
> >  	execvp(args[0], args);
> > diff --git a/src/lxc/start.c b/src/lxc/start.c
> > index 71cd9ef..6eded61 100644
> > --- a/src/lxc/start.c
> > +++ b/src/lxc/start.c
> > @@ -762,14 +762,8 @@ static int do_start(void *data)
> >  
> >  	close(handler->sigfd);
> >  
> > -	if (handler->backgrounded) {
> > -		close(0);
> > -		close(1);
> > -		close(2);
> > -		open("/dev/zero", O_RDONLY);
> > -		open("/dev/null", O_RDWR);
> > -		open("/dev/null", O_RDWR);
> > -	}
> > +	if (handler->backgrounded && null_stdfds() < 0)
> > +		goto out_warn_father;
> >  
> >  	/* after this call, we are in error because this
> >  	 * ops should not return as it execs */
> > diff --git a/src/lxc/utils.c b/src/lxc/utils.c
> > index 467bc1b..da9548f 100644
> > --- a/src/lxc/utils.c
> > +++ b/src/lxc/utils.c
> > @@ -1445,3 +1445,25 @@ domount:
> >  	INFO("Mounted /proc in container for security transition");
> >  	return 1;
> >  }
> > +
> > +int null_stdfds(void)
> > +{
> > +	int fd;
> > +
> > +	fd = open("/dev/zero", O_RDONLY);
> > +	if (fd < 0)
> > +		return -1;
> > +
> > +	dup2(fd, 0);
> 
> Well, I've seen the code above redirecting fd 0 to /dev/zero, but I think
> this is potentially dangerous, and /dev/null should be used instead for
> fd 0, too.
> 
> With /dev/zero, any reader process would get an endless stream of
> zeros, which could result in unexpected hangs or crashes, depending on
> what the reader process does.  Reading from /dev/null is safe, because
> it returns immediately, with an empty buffer.

Sure, I can resend with /dev/null instead; I thought about that, but I
was worried I was missing something r.e. /dev/zero instead.

Tycho

> 	Robert
> 
> 
> > +	close(fd);
> > +
> > +	fd = open("/dev/null", O_WRONLY);
> > +	if (fd < 0)
> > +		return -1;
> > +
> > +	dup2(fd, 1);
> > +	dup2(fd, 2);
> > +	close(fd);
> > +
> > +	return 0;
> > +}
> > diff --git a/src/lxc/utils.h b/src/lxc/utils.h
> > index 6bd05e0..ee12dde 100644
> > --- a/src/lxc/utils.h
> > +++ b/src/lxc/utils.h
> > @@ -280,4 +280,5 @@ int is_dir(const char *path);
> >  char *get_template_path(const char *t);
> >  int setproctitle(char *title);
> >  int mount_proc_if_needed(const char *rootfs);
> > +int null_stdfds(void);
> >  #endif /* __LXC_UTILS_H */
> > -- 
> > 2.1.4
> > 
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel


More information about the lxc-devel mailing list