<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On 25 November 2015 at 16:14, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, 24 Nov 2015 18:07:34 +0100<br>
Mariusz Ceier <<a href="mailto:mceier%2Bwayland@gmail.com">mceier+wayland@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> On 24 November 2015 at 17:35, Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>><br>
> wrote:<br>
><br>
> > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier <<a href="mailto:mceier%2Bwayland@gmail.com">mceier+wayland@gmail.com</a>>:<br>
> > > Hi,<br>
> > >   How the clients will know:<br>
> > > a) which interface is restricted and which is not ?<br>
> ><br>
> > It doesn't, but does it need to know it? It can still ask for<br>
> > authorization even if the interface is not.<br>
> ><br>
> ><br>
> I think it should - otherwise client, that wants to run on as many<br>
> compositors as possible, would have to send authorize requests for every<br>
> interface, since different compositors can implement different policies and<br>
> interface in one compositor can be unrestricted while in another<br>
> restricted.<br>
<br>
</span>Why should we separate restricted interfaces in the registry level? Or<br>
at all?<br>
<br></blockquote><div><br></div><div>Because binding restricted interface kills client and since interface specification doesn't tell if that interface is restricted or not, binding would be a gamble for client. Also to authorize the client to use of restricted interface, authorizer object needs to be created - that means restricted interfaces can't be bound before authorizer object is announced, and that means restricted interfaces can't be announced before authorizer is announced, unless client can bind them later (which I don't think is a case).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The interface specification needs to say whether it is restricted or<br>
not. If a compositor does not care about restricting it, it'll just<br>
always answer "yes."<br></blockquote><div><br></div><div>Even if interface specification would include information whether it's restricted or not, that information would have to be included in protocol - since later versions of protocol can become restricted.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
When you design a new protocol extension, I can't imagine that you<br>
would not know if it needs to be restricted or not. Do you have any<br>
example to the contrary?<br></blockquote><div><br></div><div>I think it may be the case during development and even after it gets stabilized. </div><div>It may be unrestricted at first, but then someone might find security bug (in design) or request requiring privileged access could be added - in these cases compositors probably would like to restrict access to that interface.</div><div>In v1 of authorizer that would mean, that clients which assumed that specific interfaces are unrestricted would be killed by compositor.</div><div>And in v2 authorizer clients would know that they need to send authorize request first - since interface wouldn't be available in wl_registry but only in wl_restricted_registry.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> > > b) that the compositor implements restricted interface ? should they be<br>
> > > visible in the registry ?<br>
> ><br>
> > Well, they are normal globals so they will are available in the<br>
> > registry. If needed, this interface could<br>
> > send out a list of the restricted ones, but i'm not sure it is.<br>
> ><br>
> ><br>
> If they're normal globals - registry will contain a mix of restricted and<br>
> unrestricted interfaces, and in current state clients won't know which is<br>
> restricted and which is not, and binding to restricted interface will kill<br>
> client - are we playing russian roulette ? ;)<br>
<br>
</span>Clients do not go binding random globals without knowing the<br>
specification.<br></blockquote><div><br></div><div>Still specification doesn't say which protocol is restricted and which is not. In v1 authorizer clients can't assume that specific interface is always unrestricted (it could become restricted in later version or compositor could implement different policy), so they would have to send authorize request for each interface they use.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I think something like wl_registry but for restricted interfaces only, may<br>
> be a better solution.<br>
<br>
</span>I see no need for this.<br>
<span class=""><br>
> Also since authorizer is another global, it would have to be announced<br>
> before any restricted interface, right ?<br>
> That requirement probably should be added to description.<br>
<br>
</span>There is no such requirement. Clients *must* deal with arbitrary<br>
announcements orders anyway.<br>
<br></blockquote><div>Except they would get killed for trying to bind  restricted interface without sending authorize request - and they can't send it before getting authorizer object (in v1). So v1 introduces weak order here.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
pq<br>
</blockquote></div><br></div><div class="gmail_extra">Mariusz Ceier<br></div></div>