-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make it possible to create composable libraries of Landlock rules #25
Comments
Such a Option A - fully compatibleMake the PathOpt struct be able to compose itself, e.g.
and extend all its methods accordingly.
Option BInheritance hierarchy
=> also no composition across FS and net rules... Option C - turn types to runtime errorsRule is the interface for options
Note: Slight API breakage, but probably OK to do for most use cases. The two use cases on Github do something like
That would continue to work because people tend to not spell out the return type of Known API breakages:
Considerations:
|
I am strongly leaning towards C, but will let it sink a little bit before committing. |
* Make `restrictOpt` public and name it `Rule`. * Rename old `PathOpt` struct type to `FSRule`. * Make `PathOpt` an alias for `Rule`. * Change mentions of the words "opts" or "option" to "rule". This is not a fully backwards-compatible change, but it works for the go-landlock users which I have discovered on Github, using the API roughly in the following way: ``` var opts []landlock.PathOpt // repeatedly opts = append(opts, landlock.RWDirs(...)) // then landlock.V2.RestrictPaths(opts...) ``` The approach is also discussed in issue #25.
Work is happening on the |
Users should be able to group their own libraries of commonly used rules that are used together
idea:
(This is just an example -- the details of these rules are not really fleshed out)
The text was updated successfully, but these errors were encountered: