Patch 2 #1
Open
Patch 2 #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…urrent task In this case we can use /proc/self/, which is correct even if a task live in another pid namespace. Signed-off-by: Andrey Vagin <[email protected]>
New capabilities can be added, and we want to be sure that a bounding set will be set correctly in this case. Without this patch new capabilities are not dropped from a bounding set. Signed-off-by: Andrey Vagin <[email protected]>
fmt.Fscanf reads byte by byte from this file, but
this doesn't work for sysctl-s.
29279 open("/proc/sys/kernel/cap_last_cap", O_RDONLY|O_CLOEXEC
29279 <... open resumed> ) = 3
29279 read(3, "3", 1) = 1
29279 read(3, "", 1) = 0
Reported-by: @syndtr
…t_cap file Fix docker/libcontainer#452 Signed-off-by: Alexander Morozov <[email protected]>
Signed-off-by: Alexander Morozov <[email protected]>
Signed-off-by: Alexander Morozov <[email protected]>
handle ENODATA in getVfsCap
Ambient capabilities were added in Linux 4.3 and provide a way to pass on capabilities to unprivileged processes easily. Signed-off-by: Justin Cormack <[email protected]>
After getting CapBnd, Loop break too early, can't to get CapAmb value. Signed-off-by: Ma Shimiao <[email protected]>
…by#14) The old methods had an internal Load(), which is unnecessary for some use cases. For example, if you're going to drop all capabilities, you don't need to load the current set first. This commit deprecates the old New* functions and adds New*2 functions which do not include the internal Load. Callers who do need the Load will need to call it explicitly after initializing their Capabilities object. Callers who do not need the Load can just add the "2" to the function name and get more efficient/robust behavior. The "Deprecated:" paragraph syntax is recommended in [1]: To signal that an identifier should not be used, add a paragraph to its doc comment that begins with "Deprecated:" followed by some information about the deprecation. [1]: https://blog.golang.org/godoc-documenting-go-code
* Fix capHeader.pid type In C, int is 4 bytes in 32 and 64-bit systems. In Go, int is a 8 bytes in 64-bit systems. Before this fix, pid was being ignored because the kernel will always read 0 due to padding added between version and pid fields. * Update capability_linux.go
CAP_PERFMON and CAP_BPF were introduced in kernel 5.8: https://kernelnewbies.org/Linux_5.8#Introduce_CAP_BPF_and_CAP_PERFMON_security_capabilities CAP_CHECKPOINT_RESTORE was merged on the master recently and will be available in the next version of the kernel. torvalds/linux@124ea65 The capability numbers are taken from https://github.com/torvalds/linux/blob/442489c219235991de86d0277b5d859ede6d8792/include/uapi/linux/capability.h#L373-L416 Signed-off-by: Akihiro Suda <[email protected]>
…/gocapability into AkihiroSuda-kernel58
Signed-off-by: Kir Kolyshkin <[email protected]>
Go 1.17 introduced new style of adding build tags (//go:build), and some tools no longer understand old-style (// +build) tags. Add the new tag, drop the old one. Signed-off-by: Kir Kolyshkin <[email protected]>
Move the code to the top-level directory. Signed-off-by: Kir Kolyshkin <[email protected]>
In case kernel folks will ever release capability v4, the chances are high v3 is still supported. Therefore, we should not error out upon seeing an unknown version from the kernel, but assume we can go with v3. While at it, treat the uninitialized capVers as an error. Before this patch, it was still treated as an error, but "unknown capability version" is not exactly what the error is, so let's be more specific. Reported-by: Andrei Vagin <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]>
Capabilities v3 API was added by the Linux kernel 2.6.26. Since go 1.18 (no longer supported as of go 1.20 release), the minimum Linux kernel requirement is 2.6.32 (see [1]). So, it does not make sense to support capabilities v1 and v2 any more. Drop the support, returning the appropriate error message. [1] https://tip.golang.org/doc/go1.18#linux Signed-off-by: Kir Kolyshkin <[email protected]>
Commit f3cb87f added support for ambient capabilities. Unfortunately, the code added to Apply is incorrect because it uses a local variable err which is never used or returned. Found by a linter: > capability_linux.go:480:5: ineffectual assignment to err (ineffassign) > err = nil > ^ Fixes: f3cb87f Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>
capability: fix broken test
1. Use testing.TB so it can also be used from a benchmark. 2. Add a call to t.Helper. Signed-off-by: Kir Kolyshkin <[email protected]>
- do not manipulate bounding set, it is not needed; - use a single list; add one more capability to it; - set Permitted/Inheritable/Effective at once; - use Unset to unset a capability; - use loop for the last check. Signed-off-by: Kir Kolyshkin <[email protected]>
Rephrase the SIGURG prose to avoid using preemptible (or preemptable). Also, remove an inline comment which pretty much repeats what the function documentation already explained. Signed-off-by: Kir Kolyshkin <[email protected]>
Rename cleanP, fullP -> pClean, pFull. This is mostly to silence codespell, which thinks cleanP is a typo in cleanup. Kind of makes sense. Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>
Also, remove capability/.codespellrc as it's no longer needed. Signed-off-by: Kir Kolyshkin <[email protected]>
capability: test improvements
When running make test, there appears an error: /bin/sh: 1: test: go test -exec sudo: unexpected operator or /bin/sh: line 1: test: go test -exec sudo: binary operator expected (depending on which shell is used). This is caused by CMD value containing extra quotes (from RUN_VIA_SUDO=-exec "sudo -n") which test sees as an extra option. Enclose test argument in single quotes to fix the issue. Signed-off-by: Kir Kolyshkin <[email protected]>
Houston, we have a problem: $ go test -exec sudo -run AmbientCapSet -count 3 -v === RUN TestAmbientCapSet --- PASS: TestAmbientCapSet (0.00s) === RUN TestAmbientCapSet capability_test.go:113: The test needs `CAP_SETPCAP`. --- SKIP: TestAmbientCapSet (0.00s) === RUN TestAmbientCapSet capability_test.go:113: The test needs `CAP_SETPCAP`. --- SKIP: TestAmbientCapSet (0.00s) PASS ok github.com/moby/sys/capability 0.024s The solution is, tests that manipulate capabilities should be run in a separate process. Add a helper to do just that, and modify TestAmbientCapSet to use it. In particular, the child needs to call os.Exit (which it does directly, in the end, and also indirectly, via log.Fatal). Signed-off-by: Kir Kolyshkin <[email protected]>
capability: add/use testInChild helper
Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>
Current version of capsV3.Apply has a major problem: if you do something like this: c, err := capability.NewPid(pid) ... c.Set(capability.AMBIENT, capability.CAP_CHOWN) c.Apply(capability.AMBIENT) then the ambient capability will be applied to the current process, rather than the process identified by pid. Same issue for BOUNDS. For CAPS the situation is slightly different: capset(2) man page says: > EPERM The caller attempted to use capset() to modify the capabilities > of a thread other than itself, but lacked sufficient privilege. > For kernels supporting VFS capabilities, this is never permitted. Here "kernels supporting VFS capabilities" means most kernels >= v2.6.24, and all kernels >= v2.6.33. Since Go 1.18+ only supports Linux >= v2.6.32, this pretty much means "all kernels". Meaning, Apply(CAPS) with non-zero pid will try capset and return EPERM. Let's return an error early if pid is set in Apply, and add a test case. Signed-off-by: Kir Kolyshkin <[email protected]>
Makefile: fix error from test
capability: minor doc improvements
capability: Apply: deny for another process
ci: add codespell
Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: lifubang <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]>
All the prctl calls that we make (or can potentially make) are limited to 3 arguments, so it's sufficient to use Syscall (rather than Syscall6). This is mostly a cosmetic change. Signed-off-by: Kir Kolyshkin <[email protected]>
RawSyscall is preferable for syscalls that do not block, and neither of the ones used by this package do. This makes the whole thing a bit faster. Signed-off-by: Kir Kolyshkin <[email protected]>
We need to lock OS thread as this library deals with per-thread capabilities. Signed-off-by: Kir Kolyshkin <[email protected]>
The API is the same as in kernel.org/pub/linux/libs/security/libcap/cap package, although the implementation is a bit simpler (here we only set capabilities for the calling thread). Co-authored-by: lifubang <[email protected]> Signed-off-by: Kir Kolyshkin <[email protected]>
Signed-off-by: Kir Kolyshkin <[email protected]>
capability: add separate ambient and bound API
Signed-off-by: Kir Kolyshkin <[email protected]>
capability: v0.4.0 release changelog
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.