set_secure_computing_mode(SecureComputingMode::Filter) has no filter argument

[rusty-snake]

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)?

[sunfishcode]

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.

[rusty-snake]

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.

[sunfishcode]

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.

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.

[rusty-snake]

deprecate secure_computing_mode

secure_computing_mode or set_secure_computing_mode?

[sunfishcode]

Oops yes, set_secure_computing_mode.

[rusty-snake]

So basically we deprecate set_secure_computing_mode and add set_secure_computing_mode_strict() and set_secure_computing_mode_filter(filter, flags).

[sunfishcode]

Yeah, that sounds reasonable. It is less convenient if users want to change the mode dynamically, but that seems unlikely to be common.