replace PolicyKit with resmgr

[David Zeuthen]

Hi,

Sorry for the long mail, 

On Thu, 2006-07-27 at 15:51 +0200, Ludwig Nussel wrote:
> 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.

But it's extremely integral to the API. It's the _only_ unique identier
for the process that calls the method. No, pid's are not unique, not in
theory and not even in practice (on Linux it's 15-bit number IIRC). From
the D-BUS connection name we can get to other interesting bits about the
caller. Like the security context, the pid etc. etc.

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

I think we want both. They are complementary. E.g. if someone calls
Suspend() on HAL we really need to ask the X server (actually ask all of
them) if the caller is connected to a console that is presently visible.
When we got infrastructure for that we'll be requiring the privilege
desktop-console-active rather than just desktop-console.

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

OK, I'll look into that. We probably should skip the user name all
together as the daemon can get to it from the bus.

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

But it's just not that simple. If the bus goes away you need to
reconnect to the services you want (these were restarted too) and do
lots of app specific stuff, e.g. maybe you want to check whether some
state changed in the service (like on HAL: were new devices added?) and
that's just not possible to do.

That said, this is hardly a problem and I can't see why this policy
should be in libdbus: Most apps today do reconnect to both D-BUS and HAL
and that's fine - it's not that much code and the apps are coded in a
way so they just ignore what happened while not being connected and
that's fine. If the OS vendor or Linux enthusiast really wants to
restart the D-BUS or HAL services on a live system they can. I just
think it's a bad idea but YMMV.

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

Oh, it's perfectly fine. HAL and PolicyKit is stuff that should already
be in the kernel anyway; from a desktop point of view it's certainly
stuff that belongs on the same level as the kernel.

Besides, as I pointed out already, for PolicyKit _specifically_ there is
nothing wrong with restarting the service right now. Hell, I might even
make it exit(0) when it's not doing service and use activation when
someone needs calls into it. So this concern of yours with PolicyKit
using D-BUS is hereby refuted, yes?

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

No, it's actually 

 "is the caller :1.203 allowed to do hal-storage-removable-mount?" 
   -> yes/no

because the decision is based on more than only uid. For example some
process might run in a specific security context and then it got extra
privileges.

For example, if I'm a OS vendor I can label /usr/libexec/gnome-user-
share to run in a specific SELinux security context and then that code
is allowed to do org.fd.PolicyKitUtils.PunchHoleInFirewall() as uid 500.
This works because I'm as a OS vendor have verified that this exact
binary is doing the right thing because I got the source code. At the
same time the process launched from ~/Hacking/rhythmbox/src/rhythmbox
won't get this privilege as uid 500 (dependent on how the punch-hole-
in-firewall privilege is configured maybe the user get to auth as
himself). This, I think, is a pretty nice feature.

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

(actually we don't keep copies of config files in memory all the time,
not sure where you got that idea. We reread them from disk all the time
because they might have changed. This falls under optimization /
performance and is not interesting to discuss at point I think.)

> User programs do not use that interface. No doubt that
> this part of polkit is required one way or another.

I'm not convinced this can be done in a library. 

You say the library would read files from the fs - but I submit this
design is not flexible enough if you want to replace the engine that
makes the decision on whether a user is privileged. For example, our
design should be flexible enough such that the engine can ask a central
corporate server about whether the user is privileged. Or do crazy stuff
like looking at file system uuid's. And since we want the engines to be
flexible running them with user privileges just won't work - they won't
have the necessary permissions.

Another angle is auditing, you really want a paper trail to record when
someone tries to do something privileged. 

And you just cannot achieve these things with a library, it just doesn't
work.

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

Sure, I expect to write a PolicyKit-gnome library that does exactly
this. 

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

Are you still convinced this can be done in a library? Because all the
code for doing this via D-BUS is _already_ written and I think I've made
a very good case for not doing this in a library.

Cheers,
David