build: gate SELinux utilities behind selinux

[xtqqczze]

Closes #12320
Contributes to #12394
Contributes to #4400

Summary

Avoid building chcon and runcon binaries when the selinux feature is not enabled.

Both utilities depend on SELinux support, so they should not be included in builds that do not enable the corresponding feature. Using Cargo’s required-features mechanism makes this dependency explicit at the binary target level and prevents these targets from being built when SELinux support is unavailable.

This also avoids the previous approach of using compile_error! to prevent unsupported binaries from being distributed. While that approach catches the problem at compile time, it also makes otherwise valid operations such as cargo check fail when the selinux feature is disabled.

Alternatives considered

• Keep building stub binaries: This would keep the binaries available but would result in commands that cannot provide their intended functionality, for example on Windows.
• Use compile_error!: This prevents chcon and runcon from being compiled without SELinux support, but also causes commands such as cargo check to fail for configurations where selinux is disabled.
• Runtime checks: Checking for SELinux support at runtime would still require building and distributing the binaries, and would not address the fact that the utilities have an unavailable build-time dependency.
• Use Cargo's required-features: This is the approach taken here. It expresses the dependency at the binary-target level and lets Cargo skip chcon and runcon entirely when selinux is disabled.

Context

• fix: Add cross-platform stubs and gate SELinux to Linux-only #8795
• runcon, chcon: Don't fetch crates at unsupported target #10360

[codspeed]

Merging this PR will not alter performance

⚠️ 122 benchmarks spent significant time in system calls

System calls cannot be consistently instrumented, so they are not included in the measure, which understates the real cost. Please switch to the Walltime instrument to accurately measure system calls.

Measurement and system calls

• sort_unique_utf8_locale
• df_deep_directory
• cksum_raw_output
• du_all_wide_tree[(5000, 500)]
• du_deep_tree[(100, 3)]
• cksum_sysv
• cksum_default
• cksum_multiple_files
• cksum_crc
• dd_copy_64k_blocks
• …and 112 more

ℹ️ 1 benchmark has no flame graph

The flamegraph could not be generated because too much time was spent in runtime internals, making the visualization not useful for performance analysis.

• sort_dictionary_order[500000]

✅ 401 untouched benchmarks
⏩ 70 skipped benchmarks¹

---

_{Comparing xtqqczze:features-feat_selinux (e82920e) with main (a770f03)}

Footnotes

1. 70 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/resolution (fails in this run but passes in the 'main' branch)

[naoNao89]

dep cleanup is oke , but still need a temporary stub or fallback because Linux packaging expects these coreutils binaries to exist. If SELinux is disabled, chcon/runcon should exist and fail clearly, not be silently omitted.

check this

$ cargo build -p uu_chcon -p uu_runcon --target-dir /tmp/pr-bug-test
   Compiling uu_runcon v0.8.0
   Compiling uu_chcon v0.8.0
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.64s

$ echo $?
0

$ ls /tmp/pr-bug-test/debug/chcon /tmp/pr-bug-test/debug/runcon
ls: /tmp/pr-bug-test/debug/chcon: No such file or directory
ls: /tmp/pr-bug-test/debug/runcon: No such file or directory

So cargo build -p uu_chcon succeeds, but the binary is not produced. cargo build --bins also only prints a warning and exits 0:

warning: target filter `bins` specified, but no targets matched; this is a no-op
Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.12s

After my fix, the same build produces both binaries, and running them gives the intended stub error:

$ cargo build -p uu_chcon -p uu_runcon --target-dir /tmp/pr-fix-test
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.00s

$ ls /tmp/pr-fix-test/debug/chcon /tmp/pr-fix-test/debug/runcon
/tmp/pr-fix-test/debug/chcon
/tmp/pr-fix-test/debug/runcon

$ /tmp/pr-fix-test/debug/chcon
chcon: SELinux is not supported on this platform

$ /tmp/pr-fix-test/debug/runcon
runcon: SELinux is not supported on this platform

u can cherry-pick my commit if you want: a5b2b8b371eabdbb10129cd7113d029c40ce2b8f

[oech3]

GNU no linger build them by default. For example, Arch's coreutils package does not have them. Also eprintln! only stubs are not useful for compatibility for scripts.

[naoNao89]

agree

reproduce is only meant to show the Cargo failure mode: with required-features on the [[bin]] target, cargo build -p uu_chcon exits 0 while producing no chcon binary. can be surprising for CI or package scripts that treat a successful package build as meaning the expected artifacts were produced

so the question is policy:

1. Mirror GNU/common non-SELinux distro behavior: if SELinux is unavailable, omit chcon/runcon
2. Keep deterministic artifacts: if uu_chcon/uu_runcon are selected for build, produce a binary. when SELinux is unavailable, make it fail clearly at runtime

my commit implements the second option

[naoNao89]

hmm, my concern is enterprise or pkg determinism. uutils is not just a toy replacement, it targets serious distro/server use, including Ubuntu integration and cross-platform coreutils compatibility

[oech3]

Upstream (GNU) sometimes do breaking change if they considered they should do that. In my opinion, consumers should be changed too in those cases.

[oech3]

Option 2 is sometimes not ideal. If we published nohup.exe unix-stubs for Windows, it can be incorrectly used on MSYS2 and breaks scripts (*con are not used at MSYS2, but they are just broken).

So I prefer complile_error!(), but it breaks cargo check.

[oech3]

In my understanding, there is nothing we can do for -p uu_runcon or --bins --workspace --bin without cargo itself's change.

[xtqqczze]

In my understanding, there is nothing we can do for -p uu_runcon or --bins --workspace --bin without cargo itself's change.

With these changes:

$ rustc --print host-tuple
aarch64-apple-darwin
$ cargo check -p uu_runcon --bins --target x86_64-unknown-linux-gnu
warning: target filter `bins` specified, but no targets matched; this is a no-op
    Finished `dev` profile [unoptimized] target(s) in 0.51s

Because the selinux feature is not enabled, Cargo skips compilation.

[oech3]

I don't have priv to merge. @cakebaker Would you review this?