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: https://wiki.tizen.org/wiki/Security:Cynara#Policies
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.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
