Re: settings daemon D-Bus interface proposal

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]