[Dev] Integration of state management in Weston Wayland.

Dominig ar Foll (Intel OTC) dominig.arfoll at fridu.net
Tue Oct 7 13:55:41 GMT 2014

> The browser process is a security enforcing component
> of the system already. It will have all the information
> required. The browser process can make the security check.
This is not a security check but rather to pass extra information to 
Weston/Wayland, for the later to report it to Murphy.
>> In that case the Browser process needs to store the AppID of the
>> requesting App, pushes it to Weston/Wayland (the preferred mechanism
>> still needs to be defined).
> This is also possible. In the browser process:
> 	Fetch the Smack label for the App (details left as an exercise)
> 	Set the SMACK64IPOUT attribute on the socket to Weston to that
> 	Send the request
> I would suggest that having the browser process do the check
> is likely to be simpler, perform better and be easier to debug.
Yes such a model would be nice and "simple" as Crosswalk woudl behave 
like any other Apps.
>> Depending of the selected model, Weston/Wayland may need to check that
>> the requesting App has the privilege to act as a proxy for a third party
>> before accepting the request (what would be the case of Crosswalk
>> rendering process).
> Does the App have the Proxy privilege? I don't see an issue here.
> How is this special?
Issue is not open a hole where any application has a way to make a 
request under an other AppID.
We can trust Crosswalk but not any other native App.
>> Then Weston/Wayland would need to implement a secured and trusted
>> interface to provide the information to Murphy and accept enforcement in
>> return.
> OK, sounds like we need a diagram of who I talking to whom.
> If it turns out to be what I think it is, we may have to raise Murphy's
> awareness of security attributes.


More information about the Dev mailing list