Services are processes that are the only allowed to access directly to
some resources.
They have some clients that connect with them and ask for some access to
resources.
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
session ID.
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
connection identifier.
For some services it may be pid of client (probably with information
some additional information like process creation time to avoid reusing
pid trap).
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
services.
Best wishes
Lukasz
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
[email protected]
https://lists.tizen.org/listinfo/dev
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
