On Sun, Jul 26, 2020 at 5:03 PM Ian Pilcher <arequipeno@xxxxxxxxx> wrote: > > I'm tearing my hair out trying to figure out why this rule isn't > matching. > > /usr(/local)?/bin/raidcheck system_u:object_r:raidcheck_exec_t:s0 > > The rule shows up in the output of 'semanage fcontext -l', so it's > loaded, but either /usr/bin/raidcheck and /usr/local/bin/raidcheck are > still being set to bin_t. > > Is there any way to get restorecon to show the steps that it takes to > determine the context for a file? Hello, I guess this is due the rule 3 documented in https://manpages.debian.org/experimental/libselinux1-dev/selabel_lookup_best_match_raw.3.en.html (source https://github.com/SELinuxProject/selinux/blob/master/libselinux/man/man3/selabel_lookup_best_match.3): The order of precedence for best match is: 1. An exact match for the real path (key) or 2. An exact match for any of the links (aliases), or 3. The longest fixed prefix match. I guess that in your policy, there is a rule that states that /usr/bin(/.*)? is labeled bin_t. As both /usr/bin(/.*)? and /usr(/local)?/bin/raidcheck match /usr/bin/raidcheck, the order of precedence is determined by the number of characters before the first special characters (that indidate a regular expression). As /usr/bin(/.*)? has a longer "fixed prefix", it is the one that matches. Does using "/usr/bin/raidcheck system_u:object_r:raidcheck_exec_t:s0" fix your issue? If yes, you can either duplicate the line (by adding both /usr/bin/... and /usr/local/bin/...), or configure a substitution pattern such that /usr/local/bin... gets transformed into /usr/bin/... before searching for patterns. Regards, Nicolas
