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

[James Westby]

[ Please keep Colin in Cc, as I don't think he is subscribed ]

On Mon Nov 23 08:04:40 -0500 2009 Richard Hughes wrote:
> 2009/11/21 James Westby <jw+debian at jameswestby.net>
> > Once the transaction has been setup, the client sends a message
> > of "Register" to the o.d.Debconf well known name. It provides
> > the nonce that it got from the transaction. The o.d.Debconf process
> > now knows the clients unique name on the system bus and can hence
> > talk to it.
> 
> I'm not sure Registering client is a good idea, it makes the whole
> system a lot more complicated from a debugging point of view.

That may be the case, could you propose an alternative arrangement
that avoids it? How else does the backend know which client to send
the requests to?

> > Next the transaction is started, which may start a debconf process
> > to get input. The apt backend arranges it such that this debconf
> > process will run with a new "dbus" frontend. This frontend talks
> > to the o.d.Debconf process and tells it what it needs (with
> > appropriate access control).
> 
> Why access control at this stage?

Just something simple like a DBus method that can only be called by
root or similar. Would prevent attacks like one user discovering the
mysql root password by popping up a question in another users session.
The nonces protect this as well, but given that only root will ever
need to request information we might as well enforce that.

> > There are various tweaks that could be made, but constraints
> > such as the packagekit backend not controlling the debconf backend
> > make it difficult to do too much.
> 
> Right, what limitations can you see from this?

It may be that the PackageKit hints can't be used. Or at least we
need a more complex system to use them.

> > The big question in my mind is how this interacts with packagekit's
> > notion of whether the client is idle. I'm not sure at which point
> > we could read that information. Could you explain the ways that
> > information can be read please Richard?
> 
> The transaction (and thus the backend) has background (i.e. not
> important, not speed critical) and interactive (i.e. the use is
> watching the UI, rather than something happening in the background
> like a cron job). The backend currently pushes the interactive and
> background variables to the helper process as part of the environment.
> I guess it's easiest for the apt backend to proxy these to
> org.debian.Debconf and then the service can make the appropriate
> policy decisions.

That would be possible. I guess these hints can't change in the course
of a transaction?

If the environment says that the user is not watching then the dbus
debconf frontend can just force non-interactive. The system proposed
here also allows the user to log out when their transaction is running
and nothing breaks, but I'm not sure that PackageKit allows this anyway.

Thanks,

James