rustix
rustix copied to clipboard
`set_secure_computing_mode(SecureComputingMode::Filter)` has no filter argument
The C interface looks like
[[deprecated]]
int prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, struct sock_fprog *filter);
however rustix' iterface looks like
set_secure_computing_mode(SecureComputingMode::Filter)
so filter will be some garbage, mostly likely failing with EFAULT.
Since PR_SET_SECCOMP (but not PR_GET_SECCOMP) is deprecated and superseded by seccomp anyway. Do you see a good reason to fix the prctl variant? Or should we just deprecated and later remove the prctl variant in rustix and add support for seccomp(2) as seccomp_set_mode_strict() and seccomp_set_mode_filter(flags, args)?
There is a bug here, though it doesn't pass a garbage pointer; it uses prctl_2args which always passes NULL as the remaining arguments.
set_secure_computing_mode does work with SecureComputingMode::Strict, so I think the thing to do is to deprecate just SecureComputingMode::Filter. And yes, I think it's sufficient to just deprecate it. We can always add a new interface in the future, if we get requests for it.
set_secure_computing_mode does work with SecureComputingMode::Strict
+1
deprecate just SecureComputingMode::Filter
This is still a valid return value of secure_computing_mode(). And actually the only possible return value of secure_computing_mode() other than SecureComputingMode::Disabled.
This is still a valid return value of
secure_computing_mode(). And actually the only possible return value ofsecure_computing_mode()other thanSecureComputingMode::Disabled.
Ah. In that case we probably should deprecate set_secure_computing_mode and define a new function that at least supports the SecureComputingMode::Strict functionality, so that the deprecated message can recommend it as a replacement.
Edit: set_secure_computing_mode is the one that needs to be deprecated because it doesn't work for Filter.
deprecate
secure_computing_mode
secure_computing_mode or set_secure_computing_mode?
Oops yes, set_secure_computing_mode.
So basically we deprecate set_secure_computing_mode and add set_secure_computing_mode_strict() and set_secure_computing_mode_filter(filter, flags).
Yeah, that sounds reasonable. It is less convenient if users want to change the mode dynamically, but that seems unlikely to be common.