> Thanks for testing and reporting. Thank you for investigating this as well. > > Before 3.8-rc1, when multiple rules matched a path, the last matching rule in > > the file_contexts file was applied. However, in 3.8-rc1, the rule precedence > > has changed, and the chosen rule is no longer easily predictable. I think we > > should keep the older version's precedence rule to avoid breaking existing > > rules. > > > > This is a real-world example from Android: > > > > > /system(/.*)? u:object_r:system_file:s0 > > > /(vendor|system/vendor)(/.*)? u:object_r:vendor_file:s0 > > > > Before 3.8-rc1, the second rule was applied to /system/vendor because it was > > the last matching rule. However, with 3.8-rc1, the first rule is applied > > instead. In 3.8-rc1, the rules appear to be sorted by decreasing regex string > > length, leading to this incompatible behavior. > > I can reproduce the behavior. > The precedence logic was based on the common and (in my point of view) > standard SELinux file context order: > Order regular expressions based on the length of their prefix stem > (non-regex characters). I double-checked the behavior of 3.5, but the precedence rule was not based on this; My previous explanation was a bit simplified. To be precise, it first looked for literal rules that exactly matched the path, then applied the last matching regular expression rule based on the order in the file. > The precedence logic was based on the common and (in my point of view) > standard SELinux file context order: > Order regular expressions based on the length of their prefix stem > (non-regex characters). > See support/fc_sort.py in the Reference and Fedora Policy, If I understand correctly, this means the libselinux behavior was changed from using line order (and exact matches) to this new stem-based behavior, aligning with Fedora's policy order? This seems like a breaking change for non-Fedora libselinux users. For example, this change breaks the Android SELinux policy, which relied on the previous line order and exact match behavior. Now, many files are not labeled as expected.
