-
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 the handledAccessFS set configurable. #12
Comments
Need to digest a bit how to do this best; Obvious way is to just expose the field
Alternative:
Or:
The method-based API is clearly safer, but also a slightly more cumbersome to use, and it's probably more common in Go to just expose the struct fields directly. Some considerations: Fallback mechanism: In the future, it may be interesting to make the "minimal enforced set of operations" configurable. This could be made such an In other words, the configuration Possibility to configure more than the known Landlock versions: By exposing the field directly, it will be possible to use AccessFS flags that are not natively supported by the Comments are welcome. |
Regarding the "possibility to configure more than the known Landlock versions": Rationale: The scenario is:
From the perspective of go-landlock, the following things are hard to distinguish:
I think it's best to make it a hard error when callers specify HandledAccessFS sets that go-landlock doesn't know about yet. This should not be a problem for users. When future Landlock ABI versions come around the corner, they'll just have to upgrade to a newer version of go-landlock that supports the flags that they want to use. (If callers use a go-landlock provided lookup for their HandledAccessFS flags (compare issue #14), they would not end up passing in a too-broad set of flags anyway.) |
This checks that the provided set of handledAccessFS permissions is within the set known to go-landlock. (see #12)
... re-thinking this right now ... I exposed the field just like that, but in the end, it's really difficult to verify correctness... suddenly, there are Config structures that can be in an invalid state (which was previously not possible). I attempted to fix that by making sure that AccessFSSet values are all valid, but all of this is really complicated to do in the end. I'm revising this, and will not expose the |
Compare opencontainers/runtime-spec#1111 (review)
from @kailun-qin:
The text was updated successfully, but these errors were encountered: