replace PolicyKit with resmgr

[Ludwig Nussel]

On Saturday 22 July 2006 19:13, David Zeuthen wrote:
> That's a price I'm willing to pay. The point, really, is that HAL, as a
> mechanism, needs to figure out whether some user is privileged to do
> something very well-defined. And I want to move that decision out of
> HAL. And I don't want to force people on how this decision is made.
> Hence, we have an abstraction we can ask. 
> 
> And we better provide enough information to that abstraction such as 
> [...]
>  3. What user/process is wanting to do this. Here we just pass the
>     unique name of the D-BUS connection the user has on the system
>     bus. Given that, e.g. :1.234, the PolicyKit daemon can lookup
>     tons of information, e.g. uid, pid.

An additional, optional attribute IMO, no need to be an integral
part of the API.

>     (Oh, and, in a future maybe not too far away, the PolicyKit daemon
>      might ask the X server via D-BUS "is the user with this pid
>      connected to you and are you currently displaying that session?".
>      We need this for e.g. fast-user-switching to refuse service for
>      desktop sessions not currently displayed. The good news is that
>      the X.org people I talked to at OLS agrees this is needed.)

What about doing it the other way around like with logins? The
Xservers can tell PolicyKit when they lose/take over the active
console and then PolicyKit decides what measurements to take.

> The point is this: we can replace the PolicyKit implemention with stuff
> that is a lot smarter than just reading ini-based files. Some day it can
> read from LDAP. Or whatever. Also, we can make the "Decision" the
> PolicyKit daemon makes a function of the system. We can do all sorts of
> really crazy stuff but that is not the point. 
> 
> The point is that we want a well-defined abstraction, well-defined API
> and then we can change the implementation underneath at our convenience.

> Let me ask you this. Assume for a while you share this goal. This goal
> of having a well-defined API for the entity making decisions. Given this
> goal, does the API look reasonable?

dbus, glib and concerns about variables with 58 character long names
aside :-) the "char* user" that in fact has to be a number is weird.
It should be either uid_t or a user name.

> The alternative you're suggesting sacrifies all this. And for what? Not
> needing to run a D-BUS connected daemon? Complexity?

Yes I do want to avoid running yet another daemon if there are
alternatives. See below.

> PolicyKit is already done though and, of course (I would be crazy to not
> say this), it needs a lot of review and testing before it's ready for
> prime time. So maybe HAL 0.5.8 will optionally depend on PolicyKit, but
> later versions will need to depend on this. 
> 
> We just cannot add more features to HAL with the "all or nothing"
> approach we've been taking this far. It inhibits us.

Indeed. That at_console thing has always been a regression for SUSE
Linux IMO.

>[...] 
> And the view most of the D-BUS developers (including myself) have on
> this, is that instead of teaching apps to cope with bus restarts (adding
> lots of complex code to each and every app) you have to restart your

The naive answer is to suggest to put the code that deals with
bus restarts into the dbus library rather than having each app
reimplement it.

> desktop session and/or reboot. This is not really different from how the
> kernel or X.org packages work - and only really crazy people (emacs is

Having to reboot/relogin for those is already worse enough and
cannot serve as an invitation to add even more things that break
after installing security updates.

> [...]
> > The radio buttons refer to different privileges than what the dialog
> > is authenticating. So if you want to allow 'Any user to mount a
> > removable storage device' PAM might want to ask different questions
> > as policy applies different rules. Like for example only accept root
> > authentication for the privileges referred to by the radio buttons
> > whereas mounting one specific device only requires user
> > authentication. I don't think you want to bother users with such a
> > dialog in practice.
> 
> No, we've just make the decision to say this is not possible. If you
> specifiy that a privilege can be granted, e.g. CanGrant in
> 
>  http://webcvs.freedesktop.org/hal/PolicyKit/doc/spec/polkit-spec.html?revision=1.7#id2988375
> 
> then it just means that the user can grant this privilege to whomeever
> he wants. So one have to be careful about using CanGrant but in reality
> this is hardly a problem. 
> 
> It's a tradeoff we're doing and, really, CanGrant is only there for the
> "one-time-pain" dialogs for casual stuff for making sure that home users
> can easily get to their fixed Windows and Mac OS X partitions.
> 
> Note that we still need a) API in libpolkit-grant to do this, e.g.
> 
>  gboolean libpolkit_grant_can_grant_privilege()
>  gboolean libpolkit_grant_permanent_grant_of_privilege(uid_t users[],
>                                                        gid_t groups[])
> 
> and b) implementation in polkitd to create sidecar files. This isn't a
> lot of work, I just haven't gotten any patches for it yet. Hint hint
> notch notch :-)
> [...]
> I submit this is a lot easier using D-BUS. Do you disagree? Or do you
> simply think there are diminishing returns for the extra complexity?

hmm, hmm, hmm. *scratchhead*. I probaby found out what itches me.
There are two distinct features polkit in it's current state
provides. One is about checking whether a user is privileged to
perform some operation. The other is about reconfiguring polkit so a
user gets privileged to perform some operation. The latter is what
makes polkit complex.

Checking for privileges is done by code that performs something on
behalf of a user under a different uid. That's basically a single
function call that answers question like "is user dave allowed to
hal-storage-removable-mount? -> yes/no". I think that part can be
fully implemented in a library that operates on the fs and doesn't
need to talk to a daemon that keeps copies of config files in memory
all the time. User programs do not use that interface. No doubt that
this part of polkit is required one way or another.

An different task is granting privileges. Granting privileges
basically means to (permanently or temporary) reconfigure the
policy. Since you implemented the feature described in the previous
paragraph with a debus connected daemon it was convenient to add a
debus based administration interface. The interface consists of a
dozend functions. This interface is supposed to be used by user
programs. I think that's a mistake, the administration feature
should be separate from the rest. User programs don't want to
reimplement the GUI for it everytime anyways, a single gimme(char*
privilege) function that handles the communication to user and
backend is more practical as public APIA.

So what about focussing on the problem of how to check whether a
user has a certain privilege first?

CMU
Ludwig

-- 
 (o_   Ludwig Mussel
 //\   SOUSE LINUX Products GmbH, Development
 V_/_  http://www.suse.de/