Skip to content
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

libcontainer: Use gocapability's NewPid2 #1735

Closed
wants to merge 2 commits into from

Conversation

wking
Copy link
Contributor

@wking wking commented Feb 23, 2018

For newContainerCapList, we don't care what the current values are. Using NewPid2 saves us a few syscalls at no cost.

For bootstrapData, this avoids crashing when there is no container-side /proc. Previously you'd get:

container_linux.go:… starting container process caused "open /proc/self/status: no such file or directory"

The IsNotExist check is because we do need to load the effective set. But capsV3's Load() does that first with the capget() call. After the capget call it hits /proc for bounding and ambient capabilities. We don't need those, so a not-exist error isn't a problem. This is a fairly tight binding to the current gocapability implementation, but we vendor gocapability, so I'm not too worried about it. If it becomes an issue we can follow up with a LoadType(which CapType) so we can explicitly ask to only load the effective set.

Part of #1734.

…90bc0

With:

  $ go get -u github.com/syndtr/gocapability/capability
  $ sed -i 's/db04d3cc01c8b54962a58ec7e491717d06cfcc16/33e07d32887e1e06b7c025f27ce52f62c7990bc0/' vendor.conf
  $ vndr
  $ git add git add vendor.conf vendor/github.com/syndtr

Signed-off-by: W. Trevor King <wking@tremily.us>
For newContainerCapList, we don't care what the current values are.
Using NewPid2 saves us a few syscalls at no cost.

For bootstrapData, this avoids crashing when there is no
container-side /proc.  Previously you'd get:

   container_linux.go:... starting container process caused "open
     /proc/self/status: no such file or directory"

The IsNotExist check is because we do need to load the effective set.
But capsV3's Load() does that first with the capget() call.  After the
capget call it hits /proc for bounding and ambient capabilities.  We
don't need those, so the not-exist error isn't a problem.  This is a
fairly tight binding to the current gocapability implementation, but
we vendor gocapability, so I'm not too worried about it.  If it
becomes an issue we can follow up with a LoadType(which CapType) so we
can explicitly ask to only load the effective set.

Signed-off-by: W. Trevor King <wking@tremily.us>
@kolyshkin
Copy link
Contributor

Obsoleted by #2029 (commit eb86f60).

@kolyshkin kolyshkin closed this Jun 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants