Codecov Report

Attention: Patch coverage is 1.06383% with 93 lines in your changes missing coverage. Please review.

Project coverage is 86.53%. Comparing base (e5f7dae) to head (1527504).

@@            Coverage Diff             @@
##             main     #540      +/-   ##
==========================================
- Coverage   87.69%   86.53%   -1.17%     
==========================================
  Files          31       32       +1     
  Lines        6893     6987      +94     
  Branches      324      340      +16     
==========================================
+ Hits         6045     6046       +1     
- Misses        617      710      +93     
  Partials      231      231              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

looks like you missed my comment here: #375 (comment) :(

https://github.com/uutils/coreutils/blob/main/src/uucore/src/lib/features/selinux.rs i have been working on this and to use it on findutils

also, there is that crate https://codeberg.org/koutheir/selinux
Sorry you wasted your time :(

looks like you missed my comment here: #375 (comment) :(

@sylvestre I feel so sorry that GitHub doesn't seem to have pushed this comment to me correctly🥺, I didn't realize you had done some work on it and I didn't deliberately ignore your efforts.

also, there is that crate https://codeberg.org/koutheir/selinux Sorry you wasted your time :(

I noticed the crate as well, but I personally don't think we should try to use more c bindings in findutils, it might be more appropriate to use more pure Rust code. What do you think?

@fu050409 i am not sure TBH. I like that crates are providing some abstractions.
In the meantime, if we could remove the dependency on a library, that would be ideal

@koutheir what is your take on this if you have one ? :)

I noticed the crate as well, but I personally don't think we should try to use more c bindings in findutils, it might be more appropriate to use more pure Rust code. What do you think?

Short answer: either (1) use the selinux crate, or (2) move this implementation-dependent logic into its own crate.

Looking at the code, I see multiple hard-coded paths, constants, and logic, all relative to the current implementation details of SELinux; details that could change anytime in subtle ways that could break this Rust implementation. It seems like bad design to me to have that non-trivial amount of logic inside this program. In my opinion, that logic belongs inside a dedicated crate that abstracts it away from this program. Now of course, I prefer that logic to be written in Rust too, but for the moment, such a crate doesn't exist, as far as I know. The closest thing to it is a Rust crate (selinux/selinux-sys) that calls into the official C implementation (libselinux) in order to perform all that logic. On one hand, this implies that using that crate will pull two more Rust crates and one more C shared library as dependencies, but on the other hand, we are not introducing a dependency that is not already in the original C implementation of this program.

Full disclosure: I'm the maintainer of the selinux and selinux-sys crates.