Docker execs strings to boot up linux containers
1–8 of 8 posts
Re: Docker execs strings to boot up linux containers
#2rather than the golang wrapper by the lxc team: https://github.com/lxc/go-lxc
Re: Docker execs strings to boot up linux containers
#3rather than the golang wrapper by the lxc team: https://github.com/lxc/go-lxc
If you think there is a better way to do it, you can send a pull request.
Re: Docker execs strings to boot up linux containers
#4rather than the golang wrapper by the lxc team: https://github.com/lxc/go-lxc
Problem is because C LXC ABI is unstable and would prevent building docker under osx or win. ALso under linux you would need at least sources for liblxc(they are different for each distribution) and unstable docker daemon which is locked to specific distribution with specific version of LXC ABI is a bad thing.
Re: Docker execs strings to boot up linux containers
#5Worth noting that this is in the 'lxc' execution driver, which is no longer the default. The 'native' driver here is now the default:
https://github.com/docker/docker/tree/master/daemon/execdriv...
Re: Docker execs strings to boot up linux containers
#6Why is this a problem at all? There is no user supplied input here. There is some string mangling in commands below, but it looks like none of it can be manipulated by a malicious user. It's not a security issue. It sounds like OP just thinks that subprocesses are icky.
Re: Docker execs strings to boot up linux containers
#7Why is this a problem at all? There is no user supplied input here. There is some string mangling in commands below, but it looks like none of it can be manipulated by a malicious user. It's not a security issue. It sounds like OP just thinks that subprocesses are icky.
It's not a problem. The poster didn't put a description of what the issue was, so I would say this post should be flagged, personally
Re: Docker execs strings to boot up linux containers
#8Why is this a problem at all? There is no user supplied input here. There is some string mangling in commands below, but it looks like none of it can be manipulated by a malicious user. It's not a security issue. It sounds like OP just thinks that subprocesses are icky.
It's not a problem. The poster didn't put a description of what the issue was, so I would say this post should be flagged, personally
Well, not necessarily. It would be much less of a problem if a) a full path name were provided and b) care was taken to ensure that the path name separator had not been overridden.
As written, or with 'a' but not 'b', there may be a possibility of an attacker manipulating $PATH to cause their own identically-named executable to be invoked with Docker's own privileges.