"seccomp": {
"defaultAction": "SCMP_ACT_ALLOW",
"architectures": [
"SCMP_ARCH_X86_64",
"SCMP_ARCH_X86",
"SCMP_ARCH_X32"
],
"syscalls": [
{
"names": [
"personality"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 0,
"op": "SCMP_CMP_EQ"
},
{
"index": 0,
"value": 8,
"op": "SCMP_CMP_EQ"
},
{
"index": 0,
"value": 4294967295,
"op": "SCMP_CMP_EQ"
}
]
},
{
"names": [
"clone"
],
"action": "SCMP_ACT_ALLOW",
"args": [
{
"index": 0,
"value": 2080505856,
"op": "SCMP_CMP_MASKED_EQ"
}
]
},
{
"names": [
"getcwd"
],
"action": "SCMP_ACT_ERRNO"
}
]
}
I am testing a config.json with seccomp rules that defaults to "allow" and a syscall with the same action "allow".
Details
runc returns the error
config.jsoncould be programatically generated with this kind of redundant rules. Could runc accepts them instead and in this case drop the no-op rule about thepersonalitysyscall?In the spec about actions, it says:
But it does not say the action has to be different to the default action.
If you think runc's behaviour is correct, I could file an issue on the spec instead to say that the action has to be different than the default action.
This issue was found with runtime-tools test linux_seccomp.go.