-
Notifications
You must be signed in to change notification settings - Fork 84
Allow to adjust LinuxNamespaces #135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
8e194a2 to
91fba35
Compare
91fba35 to
e4ab673
Compare
|
@klihub indeed ... |
|
Ci is broken: |
It's not CI per se IMO, rather I think some github-related PITA that hits us with regular irregularity. What happens is that every once in a while for some reason the protobuf source is cloned with a newer timestamp than the compiled bindings. When this happens our build system tries to rebuild them, but can't since we deliberately leave protoc uninstalled... because commits touching the protocol should commit both the protobuf and the generated sources. Maybe the right thing to do would be to always install protoc and the plugins we need, then always force a recompilation, and finally check that there are no changes. Why I'm reluctant to do that is that it would also implicitly/indirectly force everyone to use the same protoc{-gen-go,} versions, since those are emitted to the generated sources... Anyway, I retriggered the workflow for you, and it looks like the coin flipped the other way this time, because it succeeded. |
Currently there is a pair of PRs (#123, #124) with security implications, and it's actively being discussed what additional infra bits we'd need (mostly the ability to lock down selected adjustment capabilities in NRI administratively) so that everybody would feel confident enough about taking those changes in. Your PR is an alternative implementation of #124, so if you have valid uses cases for all of these additional capabilities, could you chime in #124 and point to this PR of yours as an alternative ? |
808dd0b to
29bb2a8
Compare
|
@champtar We should rebase this on latest main/HEAD and allow namespace adjustment to be locked via validation. For instance, like this: https://github.com/klihub/nri/tree/devel/champtar/adjustment-namespaces |
|
@klihub if you've already done the work, do not hesitate to update this PR https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/committing-changes-to-a-pull-request-branch-created-from-a-fork |
29bb2a8 to
1e461b4
Compare
Ah, ok. Thanks for the tip. I did not realize that was possible. I pushed the updates. Is it okay with you if I leave you as the author of the updated original commits ? |
What I usually do in this situation is keep the same commit author and add what was modified in |
1e461b4 to
3d34356
Compare
3d34356 to
93c5abe
Compare
|
let's wait to rebase this on #123 |
|
pls rebase... |
One line change in api.proto and regenerate the pb.go files. Signed-off-by: Etienne Champetier <[email protected]> Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]> Signed-off-by: Krisztian Litkey <[email protected]>
93c5abe to
ef933bb
Compare
@mikebrow Rebased and pushed. |
mikebrow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just one question around the TODO..
| // AddOrReplaceNamespace records the addition or replacement of the given namespace to a container. | ||
| func (a *ContainerAdjustment) AddOrReplaceNamespace(n *LinuxNamespace) { | ||
| a.initLinuxNamespaces() | ||
| a.Linux.Namespaces = append(a.Linux.Namespaces, n) // TODO: should we dup n here ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by this TODO? oci only allows one namespace per type and the func we are calling AddOrReplaceLinuxNamespace ensures that..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikebrow It's related to the similar comments about the corresponding helpers for mounts and [CDI] devices (as this is done consistently with those).
Basically we append here the user-supplied n *LinuxNamespace as such to the set of adjustments, as opposed to appending a copy of it. That (being a pointer) allows the user, in principle, to modify it once it has been recorded as an adjustment.
Since the plugin can only shoot itself in the foot with that, I think no too big harm is done. But I think it's good to have the comments in place, so that if we ever decide to change one, we update all the others consistently.
Signed-off-by: Etienne Champetier <[email protected]> Update adjustment plugin ownership tracking and conflict detection using the revised pkg/api-based infra. Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]> Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Etienne Champetier <[email protected]> Signed-off-by: Krisztian Litkey <[email protected]>
Add LinuxNamespace plugin/owner lookup for validation. Signed-off-by: Krisztian Litkey <[email protected]>
Implement configurable restriction of namespace adjustment in the default validator. Signed-off-by: Krisztian Litkey <[email protected]>
Signed-off-by: Krisztian Litkey <[email protected]>
ef933bb to
7d06097
Compare
mikebrow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
2 use cases I have in mind: