[Dev] Cynara session ID
l.wojciechow at partner.samsung.com
Fri May 16 09:22:44 GMT 2014
Services are processes that are the only allowed to access directly to
They have some clients that connect with them and ask for some access to
Services should check if a client is allowed to access resource. This
can be done with a request to cynara.
Such request needs to contain information about client (client ID =
SMACK label in Tizen + user ID = UID)
and a name of privilege related to resource.
For most cases a simple answer ALLOW / DENY would be enough, but we can
imagine more complex behavior with UI popup involved - that asks user if
[s]he allows the application to access the given privilege. It may be
useful to define policy the way, that a user is asked only once for
application life. This what defines life of an application is client
As service is the only one, who can access the resource, he can grant an
access even without asking cynara. We cannot stop that. Of course
services providing access to platform resources should be trusted and
use access control. But it is up to service, what it understands as session.
For some services that needs a dbus or socket connection - it may be a
For some services it may be pid of client (probably with information
some additional information like process creation time to avoid reusing
Some services may provide some cookie mechanism. Cookie once created by
a service is passed with every client request to a service and service
uses it as client session ID.
Finally some services may ignore this parameter and never use it.
It is completely up to service, what it understands as client session id.
I understand that it may be difficult to use this parameter in dbus, but
it wasn't designed to be used by a dbus. It was designed to be used by
Using session ID is optional. Some privilege
W dniu 2014-05-16 09:56, Jussi Laako pisze:
> On 15.5.2014 21:22, Patrick Ohly wrote:
>> client_session - /string/ - identifier of application life or
>> session. It might be needed for checking access granted for
>> single session. It is service responsibility to define session
>> properly, e.g. it can be defined as PID of application process
>> or service-application connection identifier. libCynara do not
>> interpret this string - it is just compared to previous ones to
>> distinguish sessions.
>> I can image that a modified dbus-daemon can be configured to map a
>> certain interface or certain methods in an interface to certain
>> privileges, but configuring it to somehow create a client_session string
>> for a certain caller is probably going too far. Such functionality is
>> better provided by custom code in the service itself.
> It already knows about client PID, but it can also provide other
> information about the dbus connection (usually there should be a
> separate connection for each application).
> So I don't see any issues here.
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev