[dpdk-dev] [PATCH v2 2/4] net/mlx4: spawn rdma-core dependency plug-in

[Shahaf Shuler]

Hi Marcelo, 

Saturday, January 27, 2018 5:03 PM, Marcelo Ricardo Leitner:
> On Fri, Jan 26, 2018 at 03:19:00PM +0100, Adrien Mazarguil wrote:
> ...
> > +static int
> > +mlx4_glue_init(void)
> > +{
> > +	char file[] = "/tmp/" MLX4_DRIVER_NAME "_XXXXXX";
> > +	int fd = mkstemp(file);
> ...
> > +	while (off != mlx4_glue_lib_size) {
> > +		ssize_t ret;
> > +
> > +		ret = write(fd, (const uint8_t *)mlx4_glue_lib + off,
> > +			    mlx4_glue_lib_size - off);
> > +		if (ret == -1) {
> > +			if (errno != EINTR) {
> > +				rte_errno = errno;
> > +				goto glue_error;
> > +			}
> > +			ret = 0;
> > +		}
> > +		off += ret;
> > +	}
> > +	close(fd);
> > +	fd = -1;
> > +	handle = dlopen(file, RTLD_LAZY);
> > +	unlink(file);
> 
> This is a potential security issue. There are no guarantees that the file
> dlopen() will open is the file that was just written above. It could have been
> changed by something else in between.

Can you further explain what are the potential risks you want to protect from?
I think this issue is not different from regular file protection under Linux. 

If the DPDK process ran by root, then this approach is no less secure than the previous version of the patches that dlopen the /usr/lib/libibverbs.so and /usr/lib/libmlx5.so.  root can also change them before the dlopen. 
In fact in terms of security, root user can intentionally damage the system in many other ways.

If the DPDK process ran by regular user X, then the only users that are allowed to modify the file created are user X and possibly root. Other users will not have write permission to it.
if the same user change this temporary file, then it damages itself only, as the DPDK process run by it will probably won't lunch. 


> 
>   Marcelo