[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