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

deps: switch to moby/sys/capability #24093

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

kolyshkin
Copy link

github.com/moby/sys/capability is a fork of the (no longer maintained)
github.com/syndtr/gocapability package.

For changes since the fork took place, see
https://github.com/moby/sys/blob/main/capability/CHANGELOG.md

Copy link

hashicorp-cla-app bot commented Oct 1, 2024

CLA assistant check
All committers have signed the CLA.

github.com/moby/sys/capability is a fork of the (no longer maintained)
github.com/syndtr/gocapability package.

For changes since the fork took place, see
https://github.com/moby/sys/blob/main/capability/CHANGELOG.md

Note that the "workaround for RHEL6" is removed for a number of reasons.
Feel free to choose the one you like the most, either is sufficient:

1. /proc/sys/kernel/cap_last_cap is available since RHEL 6.7
   (kernel 2.6.32-573.el6), released 9 years ago (2015-07-22).

2. It incorrectly returns CAP_BLOCK_SUSPEND (36), which was only added
   in kernel v3.5 and was never backported to RHEL6 kernels. The
   correct value for RHEL6 would be CAP_MAC_ADMIN (33).

3. As far as upstream kernels go, /proc/sys/kernel/cap_last_cap was
   added in kernel v3.2, and a correct value depends on the kernel
   version. It could be CAP_WAKE_ALARM (35), added to kernel v3.0, or
   CAP_SYSLOG (34), added to kernel v2.6.38, or possibly a lesser value
   for even older kernels.

Signed-off-by: Kir Kolyshkin <[email protected]>
Copy link
Member

@tgross tgross left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kolyshkin This PR updates a dependency that's worked just fine for us for many years and doesn't feel like it needs much in the way of maintenance (some software is simply "done").

In the process, you've removed a bugfix without explaining how the updated library solves it (it doesn't as far as I can tell) or at least reporting in the PR that you've determined which versions of which distros do have the /proc file in question so we can decide if that's relevant to our support requirements. I think we'd be willing to accept this PR if it came with a little more in the way of this supporting information.

@tgross tgross self-assigned this Oct 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging this pull request may close these issues.

2 participants