So, this is essentially replacing PAM as the decision mechanism by polkit.
I don't have a big problem with switching programs that use only /etc/pam.d/config-util and /etc/security/console-apps/config-util by polkit, the typical use cases are close enough, and if the respective upstreams want to, well, who are we to stop them?
The overall direction of making polkit the default mechanism is worrying, though - PAM is much more powerful due to its stable ABI for extension modules (even third-party and binary-only!), the "send a patch to polkit" approach is not nearly comparable. polkit uses PAM only through one service, making it impossible to differentiate the configuration - and the native polkit configuration options are miniscule compared to PAM. Considering that all of the PAM modules and features were created only because users needed them, what's the overall plan/vision for the features? AFAICS any reasonable future of polkit essentially means reinventing something very close to PAM.
- "For the unconverted rest, drop the usermode part and recommend to use pkexec on the command line, similar to the usual usage of sudo."
"If we did nothing, things would continue to work, nevertheless we will do work to break documented usage patterns for no good reason" That's not acceptable.
- "User Experience
- The user should experience no noticeable changes."
The change of configuration files, semantics etc. does not count as noticeable? What _would_ count as noticeable?
- "How To Test
- # yum remove usermode usermode-gtk
- should succeed for an installation with all Fedora packages installed."
A mere 10-minute check of users of usermode shows that the scope will need to include enhancements to polkit or pkexec (to handle mock, pure-ftpd, preupgrade).
- "Access control of privileged operations for ordinary users should be handled exclusively by a centrally managed authority."
polkit is no more centrally-managed than PAM - local files, one per service. Both polkit and PAM will continue to exist, so this does not simplify the overall situation. Other references to enterprise/network centralization/consistency are similarly red herrings.
--Mitr 11:23, 7 May 2012 (UTC)
- So, this is essentially replacing PAM as the decision mechanism by polkit.
No, it is not. polkit is using PAM. Anyway, this feature is about replacing usermode, not about replacing PAM.
- AFAICS any reasonable future of polkit essentially means reinventing something very close to PAM.
No, absolutely not. PAM is a horrible API that actively works against us in implementing user-friendly authentication support. The unlimited extensibility of PAM that you cite as a 'power' has the immense downside that it is nearly impossible to implement a reasonable frontend for PAM without contortions or assumptions. But again, this feature is about replacing usermode, not not about replacing PAM.
- The change of configuration files, semantics etc. does not count as noticeable? What _would_ count as noticeable?
I agree that the user experience will change. But I think the most significant user experience change is that we will show the same dialog whenever privileges are needed, which is a much-needed consistency improvement and will make things feel much more integrated.
The fact that configuration files change is more of an administrator/packager experience change, but it is well worth mentioning, indeed.
- Other references to enterprise/network centralization/consistency are similarly red herrings.
polkit has a well-defined backend abstraction that was designed with the goal to make a centralized backend easy to implement. The fact that nobody has done so yet doesn't negate the value of the abstraction.
--mclasen 00:52, 10 May 2012 (UTC)