That’s how polkit used to work. It was changed, presumably because the old system was excessively complex and inflexible. Arbitrary code is the correct solution when the set of potentially needed behaviors is unbounded, which in this case it is.
Another example of this is CSS. The vast majority of its features today—shadow effects, filter effects, animations, layout modes, even text colors—could have been implemented with WebAssembly and shaders. Instead, all of this stuff is implemented by the browser, and as a result, there are only three browser engines, two of them are on life support, and there is zero hope of meaningful competition among browsers ever arising again.
Let’s not overcomplicate polkit, please. It’s more than enough of an attack surface already.
Out of curiosity, which language would you prefer Polkit policies be written in?
Tbh I wouldn’t use languages but rather chainable configurations. Those could be yaml, JSON, toml etc.
I really dislike running any dynamic code for those things. I mean you really only need rbac providers and/or auth providers.
Maybe I underestimate Polkit by a far at the current state, but the 2 times I used it could have been a config file.
That’s how polkit used to work. It was changed, presumably because the old system was excessively complex and inflexible. Arbitrary code is the correct solution when the set of potentially needed behaviors is unbounded, which in this case it is.
Another example of this is CSS. The vast majority of its features today—shadow effects, filter effects, animations, layout modes, even text colors—could have been implemented with WebAssembly and shaders. Instead, all of this stuff is implemented by the browser, and as a result, there are only three browser engines, two of them are on life support, and there is zero hope of meaningful competition among browsers ever arising again.
Let’s not overcomplicate polkit, please. It’s more than enough of an attack surface already.