On Wed, Dec 11, 2024 at 4:10 AM Takaya Saeki <takayas@xxxxxxxxxxxx> wrote: > > > 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. > We can't break Android, so I think we will have to revert this patch for now. Jim
