cmd: generate: add --linux-namespace-* family of flags#288
cmd: generate: add --linux-namespace-* family of flags#288dqminh merged 4 commits intoopencontainers:masterfrom
Conversation
870cde8 to
081b841
Compare
|
@Mashimiao @liangchenye @wking PTAL |
|
we already have --user --memory --ipc --mount --network --pid --uts to add namespaces, I think |
|
@Mashimiao Yeah, you're right. However, we should probably have something like |
|
If the value of current namespace options is |
|
On Mon, Dec 12, 2016 at 10:33:19PM -0800, Ma Shimiao wrote:
If the value of current namespace options is `host`, we will remove
existing namespace.
Ah, right, I'd forgotten about that.
But I think that --linux-namespace-* is clear for users to
understand and use. How about removing namespace options like
--uts, --user, --pid, etc? @mrunalp @liangchenye @wking
Sounds good to me (it has better namespacing). This PR still needs
the associated man-page changes.
|
db15cb8 to
247bfaf
Compare
|
I've updated this PR so that it removes the old namespace flags, and added documentation changes for them. /cc @Mashimiao @mrunalp |
|
@cyphar please also update completions/bash file |
|
@Mashimiao Done. There were a few other flags not included or incorrectly classified, so I've fixed it up. |
wking
left a comment
There was a problem hiding this comment.
One nit and one caveat, but otherwise looks good to me :).
cmd/oci-runtime-tool/generate.go
Outdated
| } | ||
|
|
||
| func parseNamespace(ns string) (string, string, error) { | ||
| parts := strings.Split(ns, ":") |
There was a problem hiding this comment.
Split → SplitN? Linux allows paths to contain colons.
| // Add default user namespace. | ||
| if len(uidMaps) > 0 || len(gidMaps) > 0 { | ||
| needsNewUser = true | ||
| g.AddOrReplaceLinuxNamespace("user", "") |
There was a problem hiding this comment.
This will silently create an invalid config with --uidmappings=… --linux-namespace-add=user:foo, because the resulting config with call for tweaking a joined namespace. I'm pro-tweaking though, and we're already doing something silent about this case, so I'm ok with that ;). Folks who want to ensure validity can pass their final config through to validate as a separate step.
There was a problem hiding this comment.
I don't think it'll generate an invalid config, because the --linux-namespace-add handling is done afterwards and so the user entry will be replaced.
There was a problem hiding this comment.
Well, sorry, it will generate an invalid config, but the user asked us to generate it...
cb10076 to
a0f56f2
Compare
|
a0f56f2 looks good to me.
|
| } | ||
|
|
||
| func parseNamespace(ns string) (string, string, error) { | ||
| parts := strings.SplitN(ns, ":", 2) |
There was a problem hiding this comment.
If we don't check parts[0], then :testpat will also be a valid value. Though user set it, I think we should warn user it's invalid, as I did in #292
There was a problem hiding this comment.
You can validate it against the spec's whitelist. But I'm fine punting validation to a post-generate call (for callers who care). Maybe they intend to fix the values in post-processing.
There was a problem hiding this comment.
I've fixed it to check parts[0]. The whitelist checking should be done in the generate library (IMO), and I'll punt it for now. I mean, we don't actually have tests for generate at all -- so maybe we should do that first? 😉
There was a problem hiding this comment.
There aren't any unit tests or integration tests for oci-runtime-tool. We should probably add some. Also, this tool isn't versioned which makes packaging annoying.
There was a problem hiding this comment.
More importantly, as far as I can tell there's no tests of the validation -- which is quite worrying.
There was a problem hiding this comment.
Yes, we should add unit tests. unit tests for validation already in #273
There was a problem hiding this comment.
I'd floated some sharness stubs for testing in #180. Happy to rebase if there is renewed interest.
a0f56f2 to
737aa11
Compare
cmd/oci-runtime-tool/generate.go
Outdated
| return parts[0], parts[1], nil | ||
| } | ||
|
|
||
| panic("should not be reached") |
There was a problem hiding this comment.
Actually, I don't like this. the panic error message does not tell user what's wrong clear.
I think we should give user clear error message and they don't have to hack code to find out what's wrong
There was a problem hiding this comment.
It's a panic because you literally cannot reach that part of the code. len(parts) can only have a length of 0, 1, and 2 and all cases have been handled. If I remove the panic you get errors about no return statement, even though you cannot reach that line.
There was a problem hiding this comment.
I can make the function longer to make you happy if you really want.
There was a problem hiding this comment.
All cases of len(parts) are handled, so we will never reach panic. In my opinion, panic here make no sense.
There was a problem hiding this comment.
So you want to return an error even though the actual line will never be hit? From my experience, people use panic in these situations because it's more clear that if you ever hit that line it's a programming error (not something that should happen normally).
There was a problem hiding this comment.
No, I mean do not need panic or return here. Just remove this panic, because it will never be reached
There was a problem hiding this comment.
Go won't compile that program, which is why I added panic... Go isn't clever enough to know that the line won't be hit.
There was a problem hiding this comment.
I mention this above
If I remove the panic you get errors about no return statement, even though you cannot reach that line.
go build -tags "" -o oci-runtime-tool ./cmd/oci-runtime-tool
# runtime-tools/cmd/oci-runtime-tool
../../.local/src/runtime-tools/cmd/oci-runtime-tool/generate.go:629: missing return at end of function
There was a problem hiding this comment.
How about this?
func parseNamespace(ns string) (string, string, error) {
var nsType, nsPath string
parts := strings.SplitN(ns, ":", 2)
if len(parts) == 0 || parts[0] == "" {
return "", "", fmt.Errorf("invalid namespace value: %s", ns)
}
switch len(parts) {
case 1:
nsType, nsPath = parts[0], ""
case 2:
nsType, nsPath = parts[0], parts[1]
}
return nsType, nsPath, nil
}
737aa11 to
6d7ec82
Compare
cmd/oci-runtime-tool/generate.go
Outdated
| } | ||
| } | ||
|
|
||
| if context.IsSet("linux-namespace-remove-all") { |
There was a problem hiding this comment.
This should be context.Bool("linux-namespace-remove-all"). If not, when linux-namespace-remove-all is false, ClearLinuxNamespaces function will still be called.
There was a problem hiding this comment.
I was copying what --rlimits-remove-all and --seccomp-remove-all (the only other flags of this form) do. I don't disagree, it's just that the problem exists with other flags too.
This allows users to modify what namespaces are used by a container. Signed-off-by: Aleksa Sarai <asarai@suse.de>
--uts, --user and the other flags are not properly namespaced or extensible, so remove them in favour of the new --linux-namespace-* family of flags. Signed-off-by: Aleksa Sarai <asarai@suse.de>
Signed-off-by: Aleksa Sarai <asarai@suse.de>
This is generated from "oci-runtime-tool generate -h". Signed-off-by: Aleksa Sarai <asarai@suse.de>
6d7ec82 to
eb189d5
Compare
|
/ping @opencontainers/runtime-tools-maintainers |
This allows users to modify what namespaces are used by a container.
Signed-off-by: Aleksa Sarai asarai@suse.de