Re: settings daemon D-Bus interface proposal
- From: David Zeuthen <davidz redhat com>
- To: Dan Williams <dcbw redhat com>
- Cc: networkmanager-list gnome org
- Subject: Re: settings daemon D-Bus interface proposal
- Date: Fri, 23 Feb 2007 12:03:49 -0500
On Fri, 2007-02-23 at 11:38 -0500, Dan Williams wrote:
> I don't really like this, because then there's _no_ continuity between
> the NM key request and the reply; NM has no way of tracking whether a
> reply is for a specific key request. It also means that any program can
> tell NM what key it should use, not just nm-applet. At least D-Bus
> guarantees that only one copy of nm-applet can be active at any time, so
> only one process can send secrets back to NM.
Actually, my example showed that TransactionBegin() returned a cookie
and this was passed by the client for ProvideInfo() in response to
NeedInfo(). Also, to prevent any client to connect the NeedInfo() signal
carries the ID.
So setting up a transaction involves two things
- the ID - this is not secret; any client can snoop it when NM emits
NeedInfo(). Clients should only reply to NeedInfo() if they did
TransactionBegin() and got that ID back.
- the cookie - this is a transaction-wide secret and randomly generated
by NM and returned by TransactionBegin(). This guarantees that only
the client that initiated a transaction can actually provide info.
So, the ID is about identifying the connection and is a hint that a
client should or should not reply to NeedInfo. The cookie (bad name
probably) is a way to make sure they can't.
Yeah, I should have been more clear about spelling out the details, but
note it was in the call sequence diagram already :-). Anyway, I hope
it's clear now.
David
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]