:: 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.

+

+

--[[User:Mitr|Mitr]] 13:20, 10 May 2012 (UTC)

Revision as of 13:20, 10 May 2012

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.

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.

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.

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.

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.

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.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, and JBoss are trademarks or registered trademarks of
Red Hat, Inc. or its subsidiaries in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.
The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community
maintained site. Red Hat is not responsible for content.