seccomp: fix go-specs for errnoRet #1042
Conversation
commit 3bfcde2 introduced errnoRet for seccomp syscalls but the Go specs were not implemented correctly. Signed-off-by: Giuseppe Scrivano <[email protected]>
|
@vbatts PTAL |
|
@mrunalp PTAL |
| @@ -669,7 +669,7 @@ type LinuxSeccompArg struct { | |||
| type LinuxSyscall struct { | |||
| Names []string `json:"names"` | |||
| Action LinuxSeccompAction `json:"action"` | |||
| ErrnoRet uint `json:"errno"` | |||
| ErrnoRet *uint `json:"errnoRet,omitempty"` | |||
There was a problem hiding this comment.
Wondering; Was the pointer needed? (wondering because IIRC, omitempty also omits 0, in which case the default for an uint would be a meaningful value (no override)
There was a problem hiding this comment.
I think we need the pointer here as specifying ErrnoRet = 0 has a different meaning (report success), while the default with ErrnoRet unspecified is EPERM.
I've done a test for omitempty and it seems pointers are omitted only if they are nil: https://play.golang.org/p/wnzK9EQNCOS
There was a problem hiding this comment.
Wouldn't ErrnoRet = 0 conflict with the purpose of LinuxSeccompAction ?
There was a problem hiding this comment.
I think the combination SCMP_ACT_ERRNO and ErrnoRet = 0 is useful and it is different than SCMP_ACT_ALLOW, since the syscall is not performed but it is reported as successful.
There was a problem hiding this comment.
Ah, gotcha, yes, that makes sense
There was a problem hiding this comment.
Yeah, it's critical that it be clear whether errnoRet was unset (-EPERM) or 0 (a "success" but the syscall isn't run). As an aside, this trick is used for the relatively-new seccomp syscall emulation.
There was a problem hiding this comment.
I assumed it would only be used with > 0 values (0 meaning; don't change the default); thx!
There was a problem hiding this comment.
All good, it's definitely not the intended use for seccomp. ;)
|
LGTM |
|
LGTM. |
|
LGTM |
commit 3bfcde2 introduced errnoRet
for seccomp syscalls but the Go specs were not implemented correctly.
Signed-off-by: Giuseppe Scrivano [email protected]