[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