> > Currently, genfscon rules perform prefix matching (e.g., `/sys/dev` matches > > `/sys/devices`). Directly using `match_wildcard()` would not preserve this > > behavior, as it does full match. To maintain compatibility with this existing > > prefix-matching behavior, the trailing '*' is added. > > Yes, the existing genfscon handling does prefix matching, likely as an > easy workaround for the lack of wildcard matching, so if we move to > properly supporting wildcard matching, and the policy explicitly opts > into using this new capability, I'd rather just see the policy do the > right thing with wildcards. It might mean more work to convert the > policy, but this should be easier to understand and more consistent > than silently adding a '*' wildcard at the end of every path when the > path matching supports explicit wildcards anywhere in the path. Thanks for clarification. Backward incompatibility will make it challenging to enable the new wildcard feature for Android or any systems that allow users to define genfscon rules in addition to the system policy, since enabling it breaks existing user-defined policies. It would be nice we can keep the existing rules working. On second thought, we might need the POLICYDB_CAP_GENFS_SECLABEL_WILDCARD in the first place. Instead, we could make genfscon just support wildcard, since this does not make breaking changes actually. Genfscon will be applied to either pseudo filesystems, or old filesystems such as DOS and ISO9660. Pseudo filesystems will not contain '*' or '?' in the file names, and old filesystems do not allow these characters in file names either. Thus, there should be no "*" or "?" in genfscon policies in practice. I'd appreciate your opinion. Or alternatively, we can add POLICYDB_CAP_GENFS_SECLABEL_FULL_MATCH capability for users to choose the full match behavior. Adding a statement like `genfscon_wildcard` that does full match would be another idea as well.
