[Authentication] Problem: Multiple sessions per application

[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.

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.

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."

Any other ideas?

Cheers,

Stef