[Dev] Cynara session ID

Patrick Ohly patrick.ohly at intel.com
Fri May 16 10:01:57 GMT 2014

On Fri, 2014-05-16 at 11:22 +0200, Lukasz Wojciechowski wrote:
> 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.

I understand the use case. What I am pointing out is that "application
life cycle" is not something that a service can easily determine.

> 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.

All of that is understood, too. But still, the problem remains that what
the service sees as a session is not necessarily the same as the
application session seen by the user. I tried to explain some cases
where that is not the case. What we need is a thorough and peer-reviewed
documentation on how a service can reliably and securely create a
session ID string, to avoid security mistakes and increase consistency.

I don't think it can be done at the moment (at least not in a way that
would satisfy me as a user), so I am not going to propose something.

> It is completely up to service, what it understands as client session id.

No, it's not. The goal is that the service picks something that
resembles the user's understanding of a session, because the service's
choice will be highly visible to the user (because it can cause dialogs
to pop up).

> 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.

This problem has nothing to do with D-Bus. Any service, regardless of
how it gets contacted by an app, needs to recognize sessions.

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