[Dev] Cynara session ID
jussi.laako at linux.intel.com
Fri May 16 08:58:43 GMT 2014
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.
> It's used to grant access temporarily. The Cynara Wiki page has more
> information about that:
For that purpose, dbus-daemon could generate for example UUID for each
client connection and use it as session id. Or alternatively you could
attach UUID to the dbus object path.
> 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.
I'm afraid that making an all-in-one cover-it-all API-mega-proxy with
all the extra code needed would just make the system more vulnerable.
You would need to find just hole in this mega-proxy and then you would
gain access to everything in the system and impersonate yourself as
anybody you want.
Having two stacked API implementations instead of one probably has at
least 2x the number of bugs and security issues.
More information about the Dev