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