Closed int5-grey closed 8 months ago
Thanks Carl!
We should not create another
RulesetCreated
object but something likeRulesetRef
that would not allow modification of the originalRulesetCreated
object (i.e. noRulesetCreatedAttr
implementation). Therestrict_self
method should be part of a new trait, implemented byRulesetCreated
andRulesetRef
.There is currently no way to remove the write mode of the ruleset FD, but that would make sense to be able to drop this permission. I'll work on that on the kernel side, but we should probably not wait for this new kernel feature to land.
I think I hit all the areas you guys mentioned. This will be a breaking change since we moved the restrict_self to a trait that now has to be included as an import. This should likely go in a new dot release which may work nicely with the rest of the changes that are coming.
Can you please rebase on the main branch, squash into one commit, and fix the CI issues?
I did some cosmetic changes but this looks good. Thanks!
This is a simple extension to the RulesetCreated object to allow for the object to be duplicated to a potential down-level consumer that can apply the ruleset in another thread or process without consuming the initial Ruleset. This is helpful when you have builders that will want to contain a parent ruleset copy that can be applied multiple times to new forks/threads without the need to reconstruct the builder.
It doesn't override clone to do this as there is not a great pattern for handling errors if we take that approach and
fcntl
can fail for a variety of reasons.Tested on
Ubuntu 23.04 6.2.0-20-generic
.