You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
changed the title [-]`set_secure_computing_mode(SecureComputingMode::Filter)` passes a pointer to garbage to the kernel[/-][+]`set_secure_computing_mode(SecureComputingMode::Filter)` has no filter argument[/+]on Apr 12, 2025
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 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.
Activity
sunfishcode commentedon Apr 12, 2025
There is a bug here, though it doesn't pass a garbage pointer; it uses
prctl_2args
which always passesNULL
as the remaining arguments.set_secure_computing_mode
does work withSecureComputingMode::Strict
, so I think the thing to do is to deprecate justSecureComputingMode::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(SecureComputingMode::Filter)` passes a pointer to garbage to the kernel[/-][+]`set_secure_computing_mode(SecureComputingMode::Filter)` has no filter argument[/+]rusty-snake commentedon Apr 12, 2025
+1
This is still a valid return value of
secure_computing_mode()
. And actually the only possible return value ofsecure_computing_mode()
other thanSecureComputingMode::Disabled
.sunfishcode commentedon Apr 21, 2025
Ah. In that case we probably should deprecate
set_secure_computing_mode
and define a new function that at least supports theSecureComputingMode::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 forFilter
.rusty-snake commentedon Apr 21, 2025
secure_computing_mode
orset_secure_computing_mode
?sunfishcode commentedon Apr 21, 2025
Oops yes,
set_secure_computing_mode
.rusty-snake commentedon Apr 21, 2025
So basically we deprecate
set_secure_computing_mode
and addset_secure_computing_mode_strict()
andset_secure_computing_mode_filter(filter, flags)
.sunfishcode commentedon Apr 21, 2025
Yeah, that sounds reasonable. It is less convenient if users want to change the mode dynamically, but that seems unlikely to be common.