* Reading the expected binary label from the file_contexts would avoid
the timing issue, but assumes a system where the binary labels generally
match the file_contexts
I had some off-list conversations with a few people and there seemed to
be a lot of interest in this idea, particularly as a fallback if the
binary label is not available. The approach would be:
* If the binary label is available, use that
* If the binary label is unavailable, use the expected label from the
file_contexts based on the ExecStart= path (using selabel_lookup())
This would potentially have drawbacks for systems where binaries are
moved around or typically expected to not match file_contexts.
It might also cause challenges troubleshooting why systemd used a
particular socket label ("Did it read off the binary or the
file_contexts?"), and a last potential problem I'm aware of is this
systemd bug:
https://github.com/systemd/systemd/issues/30560
Currently finding binaries does not support systemd $PATH resolution.
Determining which field from the PATH to use in the file_context lookup
could be tricky. Typically many possible fields would return a valid
context (possibly something generic like default_t or bin_t in typical
policies). There's not a clear way for systemd to prioritize one label
over another, since the actual binary may not exist yet, so we don't
know which path we will ultimately find it at.
Those are the problems I'm aware of. The first two may not be real
problems in practice. My questions to the community are:
1. Are the first two problems (binary labels expected to differ from
file_contexts, and troubleshooting systemd labeling) real problems for
people?
2. Are there suggestions on how to handle the PATH lookup problem in a
sane way if we go down the selabel_lookup() route?
-Daniel
