[Dev] Cynara session ID

Patrick Ohly patrick.ohly at intel.com
Fri May 16 10:07:55 GMT 2014

On Fri, 2014-05-16 at 11:58 +0300, Jussi Laako wrote:
> On 16.5.2014 11:32, Patrick Ohly wrote:
> > This is also my thinking: the application session identifier is
> > something separate from the pid or service-specific identifiers, and
> > therefore must be attached to processes and transferred via IPC
> > mechanisms just like pid and Smack label are already.
> The documentation you pasted was talking about PID. But it could be also 
> dbus connection id without problems.

That's not necessarily better. An app could connect to D-Bus multiple
times during an application session.

> > I don't have a strong opinion about whether this feature is useful or
> > not. I'm merely pointing out that it's part of the current Cynara design
> > and (IMHO) will be a bit problematic to implement reliably the way it is
> > designed at the moment.
> I find it problematic that there is extra API proxy that needs to 
> duplicate all remote objects and then add some strange tracking for 
> those. Adding extra layer on top of ligsignon-glib would certainly help 
> tracking real sessions due to used dbus object auto-disposal. However it 
> is lot of work to replicate all the API in some kind of proxy, it would 
> impersonate the original client and would be prone to errors.

Let's not get side-tracked with the security-check-in-proxy idea. This
mail thread here is about a core Cynara feature which needs to be
implemented properly regardless of who calls Cynara.

First we need to agree on the desired client_session semantic (when it
must change and when it should better not), then we can check how that
applies to the various scenarios in which Cynara gets called.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

More information about the Dev mailing list