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

Daniel Nicoletti dantti85-pk at yahoo.com.br
Wed Nov 25 04:18:15 PST 2009


> > But even simpler would be to
> > call debconf-comunicate --create-socket=/tmp/debconf_002
> > and let debconf-comunicate does exactly what aptdaemon
> > does, listem and write to that socket.
> 
> Having looked at the aptdaemon code, I can see why you're asking for
> this, and I don't think it's necessarily a bad thing to support in
> itself (I might quibble about the option name or make it an environment
> variable or something, but that's a detail). Certainly it would replace
> a chunk of pretty ugly code in aptdaemon.
> 
> However, in the case of PackageKit, I'm concerned about having one set
> of communications going over D-Bus, and some other set going over a
> weird (in relative terms) side channel. It doesn't seem particularly
> elegant, to my mind. You have to set up sockets with the appropriate
> permissions anyway, and make sure that the rootly backend talks to the
> right one, since we mustn't make it possible for the user to be tricked
> into answering questions from some other process, or for some other user
> to intercept the questions that the user running the PackageKit frontend
> ought to be asked. Doing the same with D-Bus is hardly all that much
> more work, and in some ways I think the security model might be easier
> to analyse if it's all within the one transport system.
> 
> I actually rather like the notion of debconf being something you can
> query over D-Bus given appropriate permissions, for a variety of reasons
> not all of which are related to PackageKit. It's an important system
> service on Debian-based systems, and there's something to be said for
> exposing it in the new world order as well even if it isn't something
> debconf has interacted with before. If the objection is because it's
> harder to implement, well, in my mind, this isn't just a one-off
> exercise.

Right, but still about the socket we can ensure the permissions on
PackageKit backend which would be quite simple.

Well if you fell like extending passthrough is best that's fine with me
since all I want is PackageKit having a nice way to handle that,
but I still think that this DBus desing that you guys wrote is
a bit complicated (or I didn't understand that well).

In my mind it would be much simpler to create something like
debconf-dbus-comunicate which would export an object with
data() and receive() methods, and hasData() signal.
Then when debconf-dbus-comunicate runs it just exports that
object interface, and stdout the DBus connection id, which
KPackageKit or Gnome-PackageKit grabs and pass to
PackageKit which sets in the env var for passthrough to use,
this way we can ensure only root's write there and it's easier
to watch if this DBus connection was closed.

I really would like to help with that if you need a hand or if
you just need to know if it would work with PK.

Best,
Daniel.


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com



More information about the PackageKit mailing list