validation: add tests for NSNewNSWithoutPath & NSInheritWithoutType

[dongsupark]

This PR is to check for tests NSNewNSWithoutPath as well as NSInheritWithoutType.

• NSNewNSWithoutPath: "If path is not specified, the runtime MUST create a new container namespace of the given type."
• NSInheritWithoutType: "If a namespace type is not specified in the namespaces array, the container MUST inherit the runtime namespace of that type."

See also #572

Signed-off-by: Dongsu Park dongsu@kinvolk.io

/cc @alban

[dongsupark]

Pushed a new commit for adding a validation test for NSInheritWithoutType.

[alban]

Testing with runc:

$ sudo validation/linux_ns_itype.t 
TAP version 13
ok 1 - inherit namespace cgroup without type
ok 2 - inherit namespace ipc without type
ok 3 - inherit namespace mnt without type
ok 4 - inherit namespace net without type
ok 5 - inherit namespace pid without type
ok 6 - inherit namespace user without type
ok 7 - inherit namespace uts without type
1..7

This one works fine for me, but I have SELinux warnings in the journal:

Apr 17 14:50:38 neptune python3[23713]: SELinux is preventing linux_ns_itype. from write access on the directory task.

  *****  Plugin catchall (100. confidence) suggests   **************************

  If you believe that linux_ns_itype. should be allowed write access on the task directory by default.
  Then you should report this as a bug.
  You can generate a local policy module to allow this access.
  Do allow this access for now by executing:
  # ausearch -c 'linux_ns_itype.' --raw | audit2allow -M my-linuxnsitype
  # semodule -X 300 -i my-linuxnsitype.pp

I guess we can ignore that.

The other one fails with runc because of opencontainers/runc#1184:

$ sudo validation/linux_ns_nopath.t 
TAP version 13
failed to create the container
namespace {"cgroup" ""} does not exist
exit status 1

The output is not valid TAP output.

@wking Should we generate a TAP "not ok" output for this error, or should we continue to use util.Fatal() here? I tried to clarify that in #621

@dongsupark Except those remarks, LGTM (but I'm not a maintainer)

[wking]

@wking Should we generate a TAP "not ok" output for this error, or should we continue to use util.Fatal() here?

Your wording on this in #621 looks good to me. However the spec currently allows create to generate an error basically whenever it wants; there's no requirement for runtimes to support cgroup namespaces or anything else (opencontainers/runtime-spec#813). I think that blows a pretty big hole in cross-runtime portability, but as long as the spec is so loose there, I'm fine with either "not ok" or exit 1 for create errors (there are likely other places where we should replace util.Fatal with a "not ok" and exit 0 though).

[zhouhao3]

@dongsupark Changes LGTM overall, As they said, maybe you need to change the TAP output.

[dongsupark]

@q384566678 As you noted, I made these two tests print out diagnostics for every possible case. I hope it could address your review.

BTW travis builds suddenly started getting broken, because of this error:

# cd .; git clone https://go.googlesource.com/lint /home/travis/gopath/src/golang.org/x/lint
Cloning into '/home/travis/gopath/src/golang.org/x/lint'...
fatal: remote error: Git repository not found
package golang.org/x/lint: exit status 128

That looks like a totally unrelated issue.

EDIT: the golint issue is now fixed. Travis builds work fine.

[zhouhao3]

LGTM
@liangchenye PTAL

[dongsupark]

@q384566678 Thanks for merging!