Increase the stack size. The child process would segfault when
allocating memory for the message.
Free the allocated memory in the parent. If the user calls clone/2,3
with the CLONE_VM flag, bad things will happen.
Ugly, ugly code yet it compiles and the tests pass. I declare success!
To start a port in a new namespace:
% see clone(2) for CLONE_NEW* flags
1> Port = alcove_drv:start([
{ns, "ipc"},
{ns, "net"},
{ns, "uts"},
{ns, "ns"},
{ns, "pid"}
]).
2> alcove:execvp(Port, "/sbin/ifconfig", ["/sbin/ifconfig", "-a"]).
ok
3> IF = alcove:stdout(Port).
<<"lo Link encap:Local Loopback \n LOOPBACK MTU:16436 Metric:1\n RX packets:0 errors:0 droppe"...>>
TODO:
* figure out how to test this
* add ifdef'ed support for user namespaces
* test fork() still works
Because the exec() functions will never return, alcove can't use a
blocking call. Until something better is worked out, return immediately
if nothing is in the mailbox.
Join Linux namespaces by specifiying the path to the processes'
namespace. Assuming a container is running on PID 13502, the path to the
net namespace will be: /proc/13502/ns/net
1> Port = alcove_drv:start().
#Port<0.1001>
2> alcove:setns(Port, "/proc/13502/ns/net").
true
3> alcove:execvp(Port, "/sbin/ifconfig", ["/sbin/ifconfig", "-a"]).
true
4> alcove:stdout(Port,0).
<<"eth0 Link encap:Ethernet HWaddr ...">>
setns(2) actually provides 2 parameters: an fd and an allowed namespace
(CLONE_NEWUTS, CLONE_NEWIPC, CLONE_NEWNET).
The second parameter is used when an fd with an unknown namespace is
passed to the process and the user wants to connect to a specific
namespace. In the case of alcove, the fd is opened by the port, so
specifying the namespace is not supported.
If alcove supports calling setns(2) by fd instead of by path, the
interface will need to be changed.
alcove acts a proxy between the Erlang VM and a forked process. It can
enforce restrictions on the child process, such as dropping privileges,
setting resource limits and chroot'ing.
The goal is to support Linux namespaces, seccomp mode and cgroups so
the port process can run in an application container.
alcove should be portable though and a subset of the features should
work on any unix, possibly even supporting the sandboxing mechanisms on
other platforms.
