Skip to content

seccomp: allow fanotify_init without CAP_SYS_ADMIN#35

Open
ychampion wants to merge 1 commit into
moby:mainfrom
ychampion:49756-fanotify-init
Open

seccomp: allow fanotify_init without CAP_SYS_ADMIN#35
ychampion wants to merge 1 commit into
moby:mainfrom
ychampion:49756-fanotify-init

Conversation

@ychampion

Copy link
Copy Markdown

Summary

  • move fanotify_init into the unconditional default allow list
  • regenerate seccomp/default.json
  • cover the unprivileged default-profile path

Why

Linux 5.13 and the 5.10.220 stable backport allow callers without CAP_SYS_ADMIN to create limited fanotify groups. The current profile rejects fanotify_init before the kernel can apply those restrictions.

Fixes moby/moby#49756.

Validation

  • make test
  • make crossbuild
  • go test -race ./... in seccomp
  • go vet ./... in both modules
  • golangci-lint run ./... in both modules
  • repeat go generate ./... in seccomp with an unchanged generated-file hash

An end-to-end Docker daemon reproduction was not run locally.

Allow the kernel to apply its post-5.13 capability restrictions instead of rejecting fanotify_init at the seccomp layer.

Constraint: Unprivileged fanotify groups remain limited by the kernel API.

Rejected: Gate the syscall on a minimum kernel version | older kernels already reject unprivileged callers with EPERM.

Confidence: high

Scope-risk: narrow

Directive: Keep default.json generated from default_linux.go.

Tested: Full module tests and vet; seccomp race tests; five Linux cross-builds; golangci-lint 2.12.2; stable code generation.

Not-tested: End-to-end Docker daemon reproduction.
Signed-off-by: ychampion <ychampion@users.noreply.github.com>
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.

Default seccomp policy does not allow calling fanotify_init without CAP_SYS_ADMIN

1 participant