When a .rule file is invalid (has invalid syntax, or fails on execution), polkitd currently logs this to syslog, but otherwise ignores the rule. This might result in a configuration where an "deny" rule is ignored and a lower-priority "allow" rule is therefore applied, contrary to user's expectations. We have the excuse that the user wrote the "deny" rule incorrectly, but still, can we do something safer? I don't know, perhaps someone else has ideas? The original reporter suggests that polkitd should refuse to start, which makes some sense, but I think the corollary, to terminate polkitd as soon as an invalid .rule file is added and polkitd notices it has been added, is not acceptable, Or perhaps polkitd should go into a "lockdown" mode, where all actions by non-root users are immediately refused if any .rule is invalid, regardless of the validity/existence/contents of other .rule files or the defaults in .action files? That's not quite as draconian, but still fairly strict. Ultimately, in every of these cases (keep current behavior / terminate polkitd / lockdown), the user has to think of looking into syslog to resolve the problem. Or we could deprecate configuring polkitd through placing files, ask everyone to use some kind of tool to install new .rules, and do extensive validation within the tool? Avoids the syslog problem, but makes it difficult to use kickstarts / build images. None of the above ideas are really attractive to me; is there something better we could do?
I'm firmly of the opinion that the user simply just needs to check that his .rules file work properly. We should definitely not try to be "smart" or "helpful" apart of logging this error to make the administrator aware that something is wrong. TBH, I think this is something that mostly hit hobbyist users - in a professional deployment, you would have a controlled list of packages and run tests to check that the .rules file you install don't cause polkitd to log any errors. You would probably even have unit tests for the .rules files you deploy yourself (by mocking/stubbing the Polkit object). Closing NOTOURBUG since we don't want any of this.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.