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

Add available LinuxSeccompFlags #1138

Merged
merged 1 commit into from
Jul 18, 2022

Conversation

saschagrunert
Copy link
Contributor

We now list the available LinuxSeccompFlag values as part of the runtime spec.

cc @alban

Comment on lines 625 to 631
// LinuxSeccompFlagTsync is the filter to synchronize all other threads of
// the calling process to the same seccomp filter tree. A "filter tree" is
// the ordered list of filters attached to a thread. (Attaching identical
// filters in separate seccomp() calls results in different filters from
// this perspective.)
LinuxSeccompFlagTsync LinuxSeccompFlag = "SECCOMP_FILTER_FLAG_TSYNC"
Copy link
Contributor

Choose a reason for hiding this comment

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

With @rata we were discussing whether to remove tsync from the spec. In the context of container runtimes, the process will call seccomp() before exec() to the entrypoint, so all other threads, if any, will be terminated anyway, so tsync does not make a difference.

Examples:

  • AFAIU crun is not multithreaded, so tsync is meaningless
  • runc is written in Go so multithreaded, but uses libseccomp-golang that always set tsync: it's not configurable because threads and Go routine are not necessarily tightly coupled.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The spec still lists all three as available:
https://github.com/opencontainers/runtime-spec/blob/main/config-linux.md#seccomp

I'm a bit concerned that it will cause confusion if we remove it.

Copy link
Member

Choose a reason for hiding this comment

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

I've added it without thinking if it made any sense as I've copied all the existing flags. I agree that it is pointless in the OCI specs, and we could drop it.

Copy link
Member

Choose a reason for hiding this comment

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

I don't think it should be removed, I think it should be marked as deprecated.

See this: #1077

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good, removed it from the code now.

specs-go/config.go Outdated Show resolved Hide resolved
specs-go/config.go Outdated Show resolved Hide resolved
Copy link
Member

@rata rata left a comment

Choose a reason for hiding this comment

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

As a side note, there is already an open PR doing this: #1108

Comment on lines 625 to 631
// LinuxSeccompFlagTsync is the filter to synchronize all other threads of
// the calling process to the same seccomp filter tree. A "filter tree" is
// the ordered list of filters attached to a thread. (Attaching identical
// filters in separate seccomp() calls results in different filters from
// this perspective.)
LinuxSeccompFlagTsync LinuxSeccompFlag = "SECCOMP_FILTER_FLAG_TSYNC"
Copy link
Member

Choose a reason for hiding this comment

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

I don't think it should be removed, I think it should be marked as deprecated.

See this: #1077

Comment on lines 626 to 630
// LinuxSeccompFlagTsync is the filter to synchronize all other threads of
// the calling process to the same seccomp filter tree. A "filter tree" is
// the ordered list of filters attached to a thread. (Attaching identical
// filters in separate seccomp() calls results in different filters from
// this perspective.)
Copy link
Member

Choose a reason for hiding this comment

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

As I pointed out in another PR doing the same, I don't think we should add a const for this: #1108 (comment)

We now list the available `LinuxSeccompFlag` values as part of the
runtime spec.

Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
Co-authored-by: Alban Crequy <muadda@gmail.com>
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
@rata
Copy link
Member

rata commented Feb 23, 2022

@saschagrunert thanks, this SGTM. It is also handling the comments that were raised by @tianon in the other PR.

I'd cc @thaJeztah and @tianon just in case. I don't mind which PR ends up being merged, but IMO there should be some coordination with authors of the other PR :)

// override this filter flag by preventing specific actions from being
// logged via the /proc/sys/kernel/seccomp/actions_logged file. (since
// Linux 4.14)
LinuxSeccompFlagLog LinuxSeccompFlag = "SECCOMP_FILTER_FLAG_LOG"
Copy link
Member

Choose a reason for hiding this comment

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

@thaJeztah since the name of these variables is different than in your PR (FlagLog and FlagAllow) I'm wondering if Docker/moby has already used your variables?
I'm inclined to merge this PR given the robust comments and that it drops the TS_SYNC flag that @rata called out

Copy link
Contributor

@kolyshkin kolyshkin left a comment

Choose a reason for hiding this comment

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

LGTM

@AkihiroSuda
Copy link
Member

ping @opencontainers/runtime-spec-maintainers

@tianon tianon merged commit a8106e9 into opencontainers:main Jul 18, 2022
@saschagrunert saschagrunert deleted the seccomp-filter-flags branch July 19, 2022 06:58
@AkihiroSuda AkihiroSuda mentioned this pull request Jan 24, 2023
@AkihiroSuda AkihiroSuda added this to the v1.1.0 milestone Feb 1, 2023
@AkihiroSuda AkihiroSuda mentioned this pull request Jun 26, 2023
12 tasks
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.

8 participants