On Tue, Dec 17, 2024 at 2:13 AM Takaya Saeki <takayas@xxxxxxxxxxxx> wrote: > > > We really shouldn't have compatibility hacks when enabling policy > > capabilities, policy capabilities *are* the compatibility hack by > > allowing systems to continue to operate in the legacy mode until such > > time as the policy has been converted. > > While this makes sense, as Stephen pointed out, neither Fedora nor Android will > be able to quickly enable this capability in reality. The speed at which a new nice-to-have feature can be adopted is generally not something I worry about, it's a new *feature*, not a bug fix so if it takes some time to be fully adopted that is okay. What I do concern myself about is the quality and long term maintainability of the kernel code, especially when user visible changes are concerned. Adding kernel complexity for changes like this, especially when they can be handled in userspace is almost always going to be a no-go as far as I'm concerned. > What do you think about > two alternative ideas for right things; just start to interpret wildcards > without introducing a new capability ... No. > or introducing a new syntax that does > wildcard full match such as `genfsconwildcard`? That seems pretty awful to me too. If you can't be bothered to actually update the policy as you should be doing when enabling a new policy capability, add the same hack you were proposing for the kernel to the compiler/linker toolchain and just start adding the '*' wildcard at the end of the paths. -- paul-moore.com
