libcontainer: fix InitArgs options func to set factory.InitPath

[nickethier]

Greetings!

From the godocs it looks like InitArgs should be setting the full path and args for the init process:

InitArgs returns an options func to configure a LinuxFactory with the provided init binary path and arguments.

This isn't the case so here is a PR to fix that + a unit test.

Thanks!
-Nick

[BooleanCat]

I don't think we should be changing the InitPath to something other than /proc/self/exe. How else would runc syncronise containerisation of the init process without this unless you provide another binary that can syncronize in the same way?

From my reading of runc's code the flow looks like:

1. Set InitPath to /proc/self/exe, set the args to [init, ... other args]
2. runc invokes a child process with /proc/self/exe init other args
3. runc and the child communicate syncronisation for a bit while namespaces and such are set up
4. the process defined in other_args[0] is execed

I think the intention of InitArgs is to enable you to change the init process that's eventually execed by the runc init child. Modying InitPath seems like a separate concern - perhaps the issue here is simply misleading wording in the comment?

The syncronisation dance I mentioned is document here in beautiful ASCII art: https://github.com/opencontainers/runc/blob/master/libcontainer/sync.go

[nickethier]

@BooleanCat Thanks for the reply!

Under most circumstances I would agree that changing to anything other than /proc/self/exe is generally odd. The use case we have is in testing. When go test runs it compiles the tests into a package.test executable. In our test cases we're launching containers through libcontainer, so /proc/self/exe isn't actually the same binary/code path that we'd use outside of tests. I think we could get around this with a TestMain but it would mean launching containers goes through a slightly different code path in testing.

Concrete example:
In Nomad the libcontainer init is started by running nomad libcontainer-shim. We have a helper to discover the path to the binary (which works in tests as well) and pass it into the libcontainer factory: https://github.com/hashicorp/nomad/blob/03bf0bb65a8c2404b53f30328f2da262d0c42370/drivers/shared/executor/executor_linux.go#L123-L127
This way the init is hit when we launch a container inside a test (instead of running package.test init which would not work). https://github.com/hashicorp/nomad/blob/03bf0bb65a8c2404b53f30328f2da262d0c42370/drivers/shared/executor/executor_linux_test.go#L94