From Fedora Project Wiki

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)

https://bugzilla.redhat.com//show_bug.cgi?id=819275 shows a problem I've run into when applying the 'pkexec wrapper script' recipe to gnome-system-log.

--mclasen 00:56, 10 May 2012 (UTC)

So, this is essentially replacing PAM as the decision mechanism by polkit.
No, it is not. polkit is using PAM.

... in a single configuration for everything, hence the decisions can happen only in polkit.

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.

There is no way to future-proof this without "unlimited extensibility". You can special-case some interfaces (username/password, smartcard PIN, etc. - and FWIW this could compatibly be added to PAM), but what happens the next time somebody invents an authentication system if the interface does not have "unlimited extensibility"? (My guess: most likely about 20% of programs will be updated to support it in the first 2 years.) Until we see how polkit handles extensibility in practice, we don't really know that it is the right interface to commit to.

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.

An abstraction that has no users has no proven value; as a rule of thumb I consider three different users would be a minimum to tune an interface to be most efficient/functional. I've been earlier pointed at http://cgit.freedesktop.org/polkit/commit/?id=674357c20c1b6cb421fea6eb6924b274ec477c0e ; if this is the suggested model for extending polkit, we will be in trouble.

--Mitr 01:19, 10 May 2012 (UTC)

There is no way to future-proof this without "unlimited extensibility". You can special-case some interfaces (username/password, smartcard PIN, : etc. - and FWIW this could compatibly be added to PAM), but what happens the next time somebody invents an authentication system if the interface : does not have "unlimited extensibility"? (My guess: most likely about 20% of programs will be updated to support it in the first 2 years.)
Until we see how polkit handles extensibility in practice, we don't really know that it is the right interface to commit to.

You cannot future-proof things this way, that is an illusion at best. Only the few special-cases that you mentioned will ever work in practice, and when somebody invents an new authentication system, you have to adjust your frontend design anyway and integrate a new special case.

I grant you that the extensibility of pam is nice for certain kinds of sysadmin hacks, but it is decidedly not nice for the users who have to use the resulting frontends, where you cannot even ask for the password and its confirmation in the same dialog because that violates the infinitely extensible api contract of PAM.

An abstraction that has no users has no proven value; as a rule of thumb I consider three different users would be a minimum to tune an
interface to be most efficient/functional.

The abstraction we are talking about here doesn't have no users. It has two single users, one of which is the current local files backend. The other is a 'null' backend, so doesn't really count. Our attempts to get the IPA team to provide a backend have not been successful yet, unfortunately.

I've been earlier pointed at http://cgit.freedesktop.org/polkit/commit/?id=674357c20c1b6cb421fea6eb6924b274ec477c0e ; if this is the
suggested model for extending polkit, we will be in trouble.

Not clear what you mean here. The commit you point out adds a new feature (shockingly, that requires new code...). It does not implement a backend, so I don't see the direct relevance here.

--mclasen 01:49, 10 May 2012 (UTC)

There is no way to future-proof this without "unlimited extensibility". <snip>
You cannot future-proof things this way, that is an illusion at best.

And yet, PAM exists, works, has 17 external modules packaged in Fedora, and there are other modules that are not packaged. Working functionality with suboptimal GUI trumps a promise of the same functionality with a better GUI in the future (if that is even promised, which is not clear) any day.

I've been earlier pointed at http://cgit.freedesktop.org/polkit/commit/?id=674357c20c1b6cb421fea6eb6924b274ec477c0e ; if this is the suggested model for extending polkit, we will be in trouble.
Not clear what you mean here. The commit you point out adds a new feature (shockingly, that requires new code...). It does not implement a backend, so I don't see the direct relevance here.

It's not shocking that new features require new code :) But PAM didn't happen because somebody was bored - the extensibility without having to patch the core library turned out to be necessary. This commit shows that this kind of extensibility does not exist in polkit, and I expect that it will have to eventually be added. Incidentally, it also suggests that the backend interface of polkit is perhaps focusing on the wrong thing - there is a backend abstraction for policy distribution that is not being used (and, after all, there are already many ways to distribute config files, e.g. puppet), but there is not an abstraction for functionality extensions.

--Mitr 13:20, 10 May 2012 (UTC)


Is it possible to configure utilities with the equivalent of UGROUPS=wheel without per-application javascript policy? Currently, we do this with /etc/security/console.apps/config-util.

As I understand it, the javascript policy mechanism is not supposed to be used at the OS vendor level. But I don't see a way to do this in the .policy XML files either.

--Mattdm (talk) 13:37, 14 February 2013 (UTC)