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

config-linux: Make linux.seccomp.syscalls OPTIONAL #768

Merged
merged 1 commit into from Apr 26, 2017

Conversation

wking
Copy link
Contributor

@wking wking commented Apr 12, 2017

Fixes #762, since the issue there has been quiet, and 1.0 may be almost upon us, so I'm nervous about leaving the issue to cook for too long ;).

This commit has gone with OPTIONAL, because a seccomp config which only sets defaultAction seems potentially valid. But I'd be ok with the “REQUIRED with length > 0” approach to fixing #762 too.

@dklyle
Copy link

dklyle commented Apr 25, 2017

Technically, OPTIONAL is the right value, but unless you specify the default action for seccomp to be SCMP_ACT_ALLOW the result will be an error at run time.

I would suggest an additional clarification to this fact in config-linux.md would be very helpful if marking syscall as OPTIONAL.

wking added a commit to wking/opencontainer-runtime-spec that referenced this pull request Apr 25, 2017
Before this commit, linux.seccomp.sycalls was required, but we didn't
require an entry in the array.  That means '"syscalls": []' would be
technically valid, and I'm pretty sure that's not what we want.

If it makes sense to have a seccomp property that does not need
syscalls entries, then syscalls should be optional (which is what this
commit is doing).

If it does not makes sense to have an empty/unset syscalls then it
should be required and have a minimum length of one.

Before 652323c (improve seccomp format to be more expressive,
2017-01-13, opencontainers#657), syscalls was omitempty (and therefore more
optional-feeling, although there was no real Markdown spec for seccomp
before 3ca5c6c, config-linux.md: fix seccomp, 2017-03-02, opencontainers#706, so
it's hard to know).  This commit has gone with OPTIONAL, because a
seccomp config which only sets defaultAction seems potentially valid.

The SCMP_ACT_KILL example is prompted by:

On Tue, Apr 25, 2017 at 01:32:26PM -0700, David Lyle wrote [1]:
> Technically, OPTIONAL is the right value, but unless you specify the
> default action for seccomp to be SCMP_ACT_ALLOW the result will be
> an error at run time.
>
> I would suggest an additional clarification to this fact in
> config-linux.md would be very helpful if marking syscall as
> OPTIONAL.

I've phrased the example more conservatively, because I'm not sure
that SCMP_ACT_ALLOW is the only possible value to avoid an error.  For
example, perhaps a SCMP_ACT_TRACE default with an empty syscalls array
would not die on the first syscall.  The point of the example is to
remind config authors that without a useful syscalls array, the
default value is very important ;).

Also add the previously-missing 'required' property to the seccomp
JSON Schema entry.

[1]: opencontainers#768 (comment)

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

wking commented Apr 25, 2017 via email

@dklyle
Copy link

dklyle commented Apr 25, 2017

I think that's much better. I think a more general statement including your text might be more informative, something along the lines of:

"Note that depending on the value of defaultAction specified, syscalls should be non-empty. For example, if defaultAction is SCMP_ACT_KILL and syscalls is empty or unset, the kernel will kill the container process on its first syscall."

But what you have provides that inference. LGTM

Before this commit, linux.seccomp.sycalls was required, but we didn't
require an entry in the array.  That means '"syscalls": []' would be
technically valid, and I'm pretty sure that's not what we want.

If it makes sense to have a seccomp property that does not need
syscalls entries, then syscalls should be optional (which is what this
commit is doing).

If it does not makes sense to have an empty/unset syscalls then it
should be required and have a minimum length of one.

Before 652323c (improve seccomp format to be more expressive,
2017-01-13, opencontainers#657), syscalls was omitempty (and therefore more
optional-feeling, although there was no real Markdown spec for seccomp
before 3ca5c6c, config-linux.md: fix seccomp, 2017-03-02, opencontainers#706, so
it's hard to know).  This commit has gone with OPTIONAL, because a
seccomp config which only sets defaultAction seems potentially valid.

The SCMP_ACT_KILL example is prompted by:

On Tue, Apr 25, 2017 at 01:32:26PM -0700, David Lyle wrote [1]:
> Technically, OPTIONAL is the right value, but unless you specify the
> default action for seccomp to be SCMP_ACT_ALLOW the result will be
> an error at run time.
>
> I would suggest an additional clarification to this fact in
> config-linux.md would be very helpful if marking syscall as
> OPTIONAL.

I've phrased the example more conservatively, because I'm not sure
that SCMP_ACT_ALLOW is the only possible value to avoid an error.  For
example, perhaps a SCMP_ACT_TRACE default with an empty syscalls array
would not die on the first syscall.  The point of the example is to
remind config authors that without a useful syscalls array, the
default value is very important ;).

Also add the previously-missing 'required' property to the seccomp
JSON Schema entry.

[1]: opencontainers#768 (comment)

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

wking commented Apr 25, 2017 via email

@dklyle
Copy link

dklyle commented Apr 25, 2017

Even better. Looks great.

@mrunalp
Copy link
Contributor

mrunalp commented Apr 26, 2017

LGTM

Approved with PullApprove

2 similar comments
@tianon
Copy link
Member

tianon commented Apr 26, 2017

LGTM

Approved with PullApprove

@hqhq
Copy link
Contributor

hqhq commented Apr 26, 2017

LGTM

Approved with PullApprove

@tianon tianon merged commit 138ad89 into opencontainers:master Apr 26, 2017
@wking wking deleted the optional-syscalls branch April 26, 2017 16:08
@vbatts vbatts mentioned this pull request Jul 5, 2017
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.

config-linux: Is syscalls really required?
5 participants