Closed gnoack closed 1 year ago
A slightly more generic approach would be to ignore a type of error: golandlock.RODirs(".Xauthority", ".gtkrc").IgnoreError(MissingObject)
.
I agree, it can do that too if necessary, or we could just expose both. I'm letting this issue bake a bit at the moment, as I don't understand the full use cases yet. (It's easy to add an extra function, but hard to remove it...)
Remark, could have been used here:
https://github.com/oxzi/gosh/blob/main/internal/hardening_linux.go#L32
Remark, could have been used here:
https://github.com/oxzi/gosh/blob/main/internal/hardening_linux.go#L32
Could you explain a bit more? It seems that this line changed.
Yes, this moved to line https://github.com/oxzi/gosh/blob/main/internal/hardening_linux.go#L27
Looking at this example again, I realize it's actually slightly different to the one that this bug started with. - I think in the "gosh" project, this is just about creating the storage directory before doing the Landlock enablement.
I'm just keeping an eye on the library usage that pops up to see whether people run into a set of problems that should better the solved in go-landlock. I recently noticed that Github is nicely listing usages of this library at https://github.com/landlock-lsm/go-landlock/network/dependents
Remark - it could have been used here as well: https://github.com/capnspacehook/whalewall/blob/master/cmd/whalewall/main.go#L150
Does golandlock need a fallback mechanism for non-existent files?
This occurred to me when landlocking some real-life programs; there are some files, such as
~/.Xauthority
or various configuration directories, which probably should show up in some programs' path restrictions, but that should be permitted to be missing. (You don't have a.Xauthority
on a Wayland-only system, for instance)Rough idea:
Need to think about it.