[packagekit] Debconf and PackageKit Was Re: Packagekit and Ubuntu

[Colin Watson]

On Tue, Feb 09, 2010 at 06:00:50AM -0800, Daniel Nicoletti wrote:
> Colin Watson wrote:
> > Daniel Nicoletti wrote:
> > > This interface being placed in /etc allow us to only let
> > > root applications to access it's methods thus making
> > > this comunication secure.
> > 
> > I don't see what /etc has to do with it.  Presumably you mean that it's
> > on the system bus, whose default policy is deny.  But we do not want
> > only root applications to access these methods!  What we want is to be
> > able to permit a *selected non-root application* to access the methods.
> > 
> > If only root processes can access these methods, then the whole point of
> > all this PackageKit stuff is reduced.  You might as well just run the
> > package manager directly.  The important thing we gain from running this
> > over D-Bus even on the local machine is that we don't have to run the UI
> > as root.
> 
> I think you missed my point here, my idea was to put this model that you
> have upside down, the debconf-communicate process will run as
> the user, but is the root process that will talk with it, not the oposite,
> that's why i said about a hasData() signal.

OK.

> For real if you don't like my methods and you already have yours
> I'm ok, actually you will do a much better job than I, I'm just
> having the felling of the need of another proxy program to be
> running on the user session which is the part I don't like,
> but of course I might misunderstood you model.
> 
> So, how will client tools start debconf as user?

The model that James outlined does involve a process to be a broker
between the PackageKit client and the debconf backend.  The number of
processes is the same, though, as that broker process is actually a
debconf frontend in and of itself, and is able to respond to debconf
commands without spawning another process to do so.  (It doesn't
necessarily have to actually display an X window all the time, of
course.)

One alternative that avoids the broker would be to have the PackageKit
client sit on org.debian.Debconf itself, and when it receives method
calls it starts up a debconf-dbus subprocess and proxies them through.
This requires more code in PackageKit to do the proxying, though, and
doesn't seem really all that useful; I think the first model also makes
it easier to implement clients other than PackageKit that use this.

> > Thanks for the note about SetHints (though as far as I can see, we need
> > to explicitly enumerate the hints we use in pk_transaction_set_hint).
> > However, I'm not sure this is necessary if Richard is already going to
> > add the transaction ID as an environment variable.  We don't need to
> > invent another ID if PackageKit already has one.
> 
> Ok, please correct if I'm wrong,
> 1 GUI get a PK_TID
> 2 GUI starts debconf-dbus with this TID (which could register org.debian.debconf.TID
> 3 The PK backend sets the TID as an ENVVAR
> 4 The debconf running as root talks to org.debian.debconf.TID

Essentially, yes, that's what we were thinking of.  There's one slight
quirk about the transaction ID format I want to check on, but I think
I'll follow up at a different point in this thread for that.

> If this is what you're doing I like it, please tell me if there is something
> I can help.

Design review is helpful, even though I've been slow to respond so far!

Thanks,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]