[Authentication] Problem: Multiple sessions per application

[Michael Leupold]

Am Sonntag, 16. August 2009 22:30:30 schrieb Stef Walter:
> Here's a problem in a certain corner case with the way we've specified
> sessions. I can't see an easy fix for it.
>
> In the current secrets API, a session is used for two things:
>
>  * Negotiating transport encryption of secrets.
>  * Tracking what has been unlocked.
>
> We only support having one session per peer on the DBus session bus.
> Unless an application uses a private DBus connections, this essentially
> limits it to one session per application, and is outlined as such in the
> spec.
>
> Once a session is established, and a client application makes a call
> (let's say accesses a secret), the service knows which session is 'in
> use' by looking up the caller's unique name on the bus (looks like
> ':1:129') and seeing if that caller has established a session. It then
> uses the session for transport encryption, and/or checking unlocks etc...
>
> So far so good.
>
> The problem is that if two different components (like libraries) in a
> single client application both want to establish a session and start
> talking to the service.
>
> Due to the way that DBus is setup they'll both share the same DBus
> connection, and both components will make their calls with the same DBus
> unique name. When one of the two components in the client application
> establishes a session, then the other will not be able to.

I'm not sure about the plain dbus way but it should be possible for one 
application to establish several connections to the bus. I just tested this 
using QtDBus and it worked.

> In addition, if transport encryption is used, then the second component
> would not be able decrypt the secrets, as it wasn't part of the
> negotiation of the transport encryption. The transport encryption is
> working as it should, and not allowing a 'third party' to see the
> secrets as they move between the service and client app.
>
> However in this case the the second component in the client application
> won't have a chance to open a new session. And even if we let it, how
> would the service know which session to 'use' when receiving calls from
> that client app.

I think the best way would be to hide all of the negotiation from the client 
library. Like that it could be done once on establishing first contact with 
the daemon and stored globally. Concurrent clients within the same application 
could then just use the same data. Would that work? I don't know enough about 
keyring's internals to judge (I seem to remember some parts were 
multithreaded).

> Is there a solution to this? Maybe, but it wouldn't be simple. Some DBus
> services, like the SessionManager, after you establish a session, they
> expose additional objects under that session for you to access in the
> context of that session. So it would look like (ssss = service id, xxxxx
> = collection id, iiiii = item id):
>
> /org/freedesktop/secrets/service/sssss/collection/xxxxxx
> /org/freedesktop/secrets/service/sssss/collection/xxxxxx/iiiii
> etc....
>
> I think that's ugly, and difficult to use. :( But maybe it's necessary?
>
> Obviously applications that use a single client library which wraps the
> secrets API, wouldn't have this problem. Though they'd still have the
> problem if they used two different client libraries.
>
> We could make it a 'Known Issue', and say something like this in the spec:
>
> "All callers using the same DBus connection, must coordinate their
> access to the secrets API, especially with regard to sessions. For this
> reason it's recommended you use a client library which coordinates your
> access to the secrets service."

Yeah, I think we should state that in the DBus specification and additionally 
give some implementational hints for people implementing a client API or 
directly accessing the daemon: Either use global session data or establish an 
additional DBus connection per session if used inside a library.

If you can, please add it to the spec. Unfortunately I'll be extremely busy 
this week and the following one.

Regards,
Michael