Fix non-Unix build of libcontainer/user

[ijc]

Commit 3d7cb42 ("Move libcontainer to x/sys/unix") switched from
syscall.Get[ug]id to unix.Get[ug]id where unix.* is (naturally) not
available on non-Unix platforms such as Windows.

Move the offending code into a Unix specific file and provide stubs in the
_unsupported.go case.

The stubs use -1 for UID and GID which is what syscall_windows.go was
returning prior to 3d7cb42, and these are laundered through Lookup[GU]id
to provide the same behaviour as before.

Signed-off-by: Ian Campbell ian.campbell@docker.com

[ijc]

This was found by moby/tool#102 / linuxkit/linuxkit#2159. Looking through the libcontainer subdir the only file I see which uses golang.org/x/sys/unix but is not using a unix or linux tag is libcontainer/utils/utils.go. I suppose that one needs to switch to golang.org/x/sys/windows.

[ijc]

CI failure is #1505, rebased to pickup #1510.

For the use of unix.WaitStatus in ExitStatus I think I might define a local interface which satisfies what ExitStatus wants to call and which unix.ExitStatus and windows.ExitStatus both meet (i.e. the Signalled, Signal and ExitStatus methods).

[ijc]

I think I might define a local interface which satisfies what ExitStatus wants to call

Unfortunately unix.Signal and windows.Signal have different types. Looks like I'll need to move the code around to have unix and windows versions.

[crosbymichael]

@ijc overall, we don't care about runc compiling on anything but linux. This wasn't the case before but after looking how different platforms will make their own runtimes we stopped this.

Can you just add build tags in your code around this import?

[dqminh]

@crosbymichael should we also start cleaning up the rest of non-linux code ?

[crosbymichael]

@dqminh probably. I think that will also prompt us to break out a few packages that are generally useful and that could support cross platform operations.

That is what I have been doing in containerd with console and cgroups(not cross platform ;) ) packages. The user package would be good to breakout if we have a way to make it work cross platform correctly.

[dqminh]

Yah, my plan is to merge console once we have the change for EpollConsole, and merge with containerd/cgroups after that

[crosbymichael]

Ya, we need that review from @mrunalp ;)

[ijc]

@ijc overall, we don't care about runc compiling on anything but linux. This wasn't the case before but after looking how different platforms will make their own runtimes we stopped this.

Right, I wasn't sure if that extended to libcontainer since it looked like it was trying to be portable, but I guess that is actually just baggage now.

Can you just add build tags in your code around this import?

It's being pulled in through nested vendoring, I think there is one path via moby/moby/pkg/homedir/homedir.go which @justincormack is going to fix, I have a feeling there was at least one more when I looked on Friday though, which I'll go and hunt down.

[ijc]

@justincormack has filed moby/moby#34040 which should avoid this call chain for our use case, so closing this.