Ian Pilcher <arequipeno@xxxxxxxxx> writes: > 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 Some suggestions in order of likelyness. It might be that due to the (/local)? part another entry that is more specific takes precedence. (try splitting the spec into two lines, or even better make /usr/local/bin the equivalence of /usr/bin). You might also be able to make it make it more specific by adding the -- filespec, which you probably should have done anyway (always be as specific as possible): /usr(/local)?/bin/raidcheck -- system_u:object_r:raidcheck_exec_t:s0 Maybe these are hardlinks? Maybe there are equivalence rules in place for these locations. Then you would have to make the spec apply to the location of which this location is the equivalence. > > 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? -- gpg --locate-keys dominick.grift@xxxxxxxxxxx Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098 Dominick Grift
