[PATCH 0/3] PolicyKit - Add Shadow authorisation database
David Zeuthen
david at fubar.dk
Fri Dec 7 09:27:20 PST 2007
Hi,
Thanks for looking at this. I think there's some general confusion in
the patch set that mixes up the two separate concepts of authorizations
and authentication
(It kinda sucks both start with auth and many people do (erroneously)
use these interchangeably so I don't blame you too much).
Here's how it's supposed to work:
1. Authorization database: this is a pluggable (at build time)
construct in PolicyKit that abstracts the underlying way of storing
authorizations. The plan is that you can implement an PK authdb that
uses e.g. Solaris RBAC under the hood. Or anything else.
The is defined in the PolKitAuthorizationDB class in polkit/
polkit-authorization-db.h. The abstraction isn't perfect; it
naturally leaks into other classes; in particular constructors
for these. Hence #ifdef's. That's not a problem though.
Right now we have two authdb's: the default one that stores
authorizations in the file system (protected by DAC) and a dummy
one that always says 'no'.
An authorization database may, or may not, allow users to gain
authorizations through authentication. Only the 'default' one has
the capability right now.
How authentication happens is really not dependent on the
authorization database. If other authdb backends surface I expect
that they should be able to use all of the authentication frameworks
we support.
2. Authentication framework: This is abstracted in the class
PolKitGrant defined in polkit-grant/polkit-grant.h. No other
part of PolicyKit even needs to care what the authentication
framework is (so I agree on patch 1 to remove unnecessary PAM
headers). So the patch for support /etc/shadow should probably
export a build option called --with-authentication=[pam|shadow].
Does this explanation make sense? Thanks.
David
More information about the hal
mailing list