On 14.5.2014 18:01, Patrick Ohly wrote:
That works because you have full control over the D-Bus API. It does not work when trying to add access control to an existing API, because it would break the API for apps already using it.
Yes, but runtimes could implement some additional callback interface to respond to application context queries from the dbus-daemon. For other cases it is not needed. If runtimes would create a separate dbus connection per each app running inside the runtime (I guess this would be the case anyway with crosswalk), then it needs to be just a property of the dbus connection.
At the moment, the patched dbus-daemon will tell clients when (and only when) they ask what the application context of a certain peer is (via GetConnectionSmackContext).
Yes, and that's what we use when gsignond is configured for session bus (instead of default p2p dbus). But the case here is different, because when dbus-daemon is doing the enforcement, the application context needs to travel only between client application and dbus-daemon and only when the client application is a runtime.
This does not address the file access issues pointed out by Rafał, which IMHO is the bigger issue.
One could restrict file open/creation to a security enforcement dbus service and use the descriptor passing to transfer the descriptor back to the crosswalk process. This would have minimal performance impact because after that point all file access would be direct.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
