<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 24 November 2015 at 17:35, Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">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>
</span>It doesn't, but does it need to know it? It can still ask for<br>
authorization even if the interface is not.<br>
<span class=""><br></span></blockquote><div><br></div><div>I think it should - otherwise client, that wants to run on as many compositors as possible, would have to send authorize requests for every interface, since different compositors can implement different policies and interface in one compositor can be unrestricted while in another restricted. </div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> b) that the compositor implements restricted interface ? should they be<br>
> visible in the registry ?<br>
<br>
</span>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>
<span class=""><br></span></blockquote><div><br></div><div>If they're normal globals - registry will contain a mix of restricted and unrestricted interfaces, and in current state clients won't know which is restricted and which is not, and binding to restricted interface will kill client - are we playing russian roulette ? ;)<br></div><div><br></div><div>I think something like wl_registry but for restricted interfaces only, may be a better solution.</div><div><br></div><div>Also since authorizer is another global, it would have to be announced before any restricted interface, right ?</div><div>That requirement probably should be added to description.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">><br>
> If the client would like to use many restricted interfaces, it would have to<br>
> issue multiple authorize requests - probably causing compositor to show many<br>
> popups/notifications. I think it would be better to send list of interfaces<br>
> and receive back a list of interfaces for which access was granted instead.<br>
<br>
</span>That's a valid point... i don't think wl_array works for strings<br>
though, so instead i'd add a way to group requests together.<br>
<br>
<br>
--<br>
Giulio<br>
<div class=""><div class="h5"><br>
><br>
> Mariusz Ceier<br>
><br>
><br>
> On 24 November 2015 at 16:16, Giulio Camuffo <<a href="mailto:giuliocamuffo@gmail.com">giuliocamuffo@gmail.com</a>><br>
> wrote:<br>
>><br>
>> This new extension is used by clients wanting to execute priviledged<br>
>> actions such as taking a screenshot.<br>
>> The usual way of granting special priviledged to apps is to fork and<br>
>> exec them in the compositor, and then checking if the client is the<br>
>> known one when it binds the restricted global interface. This works<br>
>> but is quite limited, as it doesn't allow the compositor to ask the<br>
>> user if the app is trusted, because it can't wait for the answer in<br>
>> the bind function as that would block the compositor.<br>
>> This new protocol instead allows the answer to come after some time<br>
>> without blocking the compositor or the client.<br>
>> ---<br>
>><br>
>> For reference, i've implemented this in orbital[0] and it's used by<br>
>> the screenshooter tool[1]. The name is different but it works exaclty<br>
>> the same as this one.<br>
>> One thing missing is how the revoke authorization, if even want/need it?<br>
>><br>
>> 0:<br>
>> <a href="https://github.com/giucam/orbital/blob/master/src/compositor/authorizer.cpp" rel="noreferrer" target="_blank">https://github.com/giucam/orbital/blob/master/src/compositor/authorizer.cpp</a><br>
>> 1:<br>
>> <a href="https://github.com/giucam/orbital/blob/master/src/screenshooter/main.cpp#L301" rel="noreferrer" target="_blank">https://github.com/giucam/orbital/blob/master/src/screenshooter/main.cpp#L301</a><br>
>><br>
>><br>
>>  Makefile.am                                    |  1 +<br>
>>  unstable/authorizer/authorizer-unstable-v1.xml | 90<br>
>> ++++++++++++++++++++++++++<br>
>>  2 files changed, 91 insertions(+)<br>
>>  create mode 100644 unstable/authorizer/authorizer-unstable-v1.xml<br>
>><br>
>> diff --git a/Makefile.am b/Makefile.am<br>
>> index a32e977..bfe9a6a 100644<br>
>> --- a/Makefile.am<br>
>> +++ b/Makefile.am<br>
>> @@ -5,6 +5,7 @@ unstable_protocols =<br>
>> \<br>
>>         unstable/text-input/text-input-unstable-v1.xml<br>
>> \<br>
>>         unstable/input-method/input-method-unstable-v1.xml<br>
>> \<br>
>>         unstable/xdg-shell/xdg-shell-unstable-v5.xml<br>
>> \<br>
>> +       unstable/authorizer/authorizer-unstable-v1.xml<br>
>>         $(NULL)<br>
>><br>
>>  nobase_dist_pkgdata_DATA =<br>
>> \<br>
>> diff --git a/unstable/authorizer/authorizer-unstable-v1.xml<br>
>> b/unstable/authorizer/authorizer-unstable-v1.xml<br>
>> new file mode 100644<br>
>> index 0000000..f10dd0e<br>
>> --- /dev/null<br>
>> +++ b/unstable/authorizer/authorizer-unstable-v1.xml<br>
>> @@ -0,0 +1,90 @@<br>
>> +<?xml version="1.0" encoding="UTF-8"?><br>
>> +<protocol name="authorizer_unstable_v1"><br>
>> +<br>
>> +  <copyright><br>
>> +    Copyright © 2015 Giulio Camuffo.<br>
>> +<br>
>> +    Permission to use, copy, modify, distribute, and sell this<br>
>> +    software and its documentation for any purpose is hereby granted<br>
>> +    without fee, provided that the above copyright notice appear in<br>
>> +    all copies and that both that copyright notice and this permission<br>
>> +    notice appear in supporting documentation, and that the name of<br>
>> +    the copyright holders not be used in advertising or publicity<br>
>> +    pertaining to distribution of the software without specific,<br>
>> +    written prior permission.  The copyright holders make no<br>
>> +    representations about the suitability of this software for any<br>
>> +    purpose.  It is provided "as is" without express or implied<br>
>> +    warranty.<br>
>> +<br>
>> +    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS<br>
>> +    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND<br>
>> +    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY<br>
>> +    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES<br>
>> +    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN<br>
>> +    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,<br>
>> +    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF<br>
>> +    THIS SOFTWARE.<br>
>> +  </copyright><br>
>> +<br>
>> +  <interface name="zwp_authorizer_v1" version="1"><br>
>> +    <description summary="authorize clients to use certain interfaces"><br>
>> +      This global interface allows clients to ask the compositor the<br>
>> +      authorization to bind certain restricted global interfaces.<br>
>> +      Any client that aims to bind restricted interfaces should first<br>
>> +      request the authorization by using this interface. Failing to do<br>
>> +      so will result in the compositor sending a protocol error to the<br>
>> +      client when it binds the restricted interface.<br>
>> +<br>
>> +      The list of restricted interfaces is compositor dependant, but must<br>
>> +      not include the core interfaces defined in wayland.xml. However, if<br>
>> +      an authorization request is done for a non-restricted interface the<br>
>> +      compositor must reply with a grant.<br>
>> +    </description><br>
>> +<br>
>> +    <request name="destroy" type="destructor"><br>
>> +      <description summary="destroy this zwp_authorizer_v1 object"><br>
>> +        Any currently ongoing authorization request will outlive this<br>
>> object.<br>
>> +      </description><br>
>> +    </request><br>
>> +<br>
>> +    <request name="authorize"><br>
>> +      <description summary="authorize a global interface"><br>
>> +        The authorize request allows the client to ask the compositor the<br>
>> +        authorization to bind a restricted global interface. The newly<br>
>> +        created zwp_authorizer_feedback_v1 will be invalid after the<br>
>> +        compositor sends either the granted or denied event so the client<br>
>> +        is expected to destroy it immediately after.<br>
>> +      </description><br>
>> +      <arg name="id" type="new_id" interface="zwp_authorizer_feedback_v1"<br>
>> summary="the new feedback object"/><br>
>> +      <arg name="global" type="string" summary="the global interface the<br>
>> client wants to bind"/><br>
>> +    </request><br>
>> +    </interface><br>
>> +<br>
>> +    <interface name="zwp_authorizer_feedback_v1" version="1"><br>
>> +      <description summary="feedback for an authorization request"><br>
>> +        A zwp_authorizer_feedback_v1 object is created by requesting<br>
>> +        an authorization with the zwp_authorizer_v1.authorize request.<br>
>> +        The compositor will send either the granted or denied event based<br>
>> +        on the system and user configuration. How the authorization<br>
>> process<br>
>> +        works is compositor specific, but a compositor is allowed to ask<br>
>> +        for user input, so the client must not assume the reply will come<br>
>> +        immediately.<br>
>> +      </description><br>
>> +<br>
>> +      <event name="granted"><br>
>> +        <description summary="the authorization was granted"><br>
>> +          The authorization was granted. The client can now bind the<br>
>> restricted<br>
>> +          interface.<br>
>> +        </description><br>
>> +      </event><br>
>> +<br>
>> +      <event name="denied"><br>
>> +        <description summary="the authorization was denied"><br>
>> +          The authorization was denied. The client is not allowed to bind<br>
>> the<br>
>> +          restricted interface and trying to do so will trigger a<br>
>> protocol<br>
>> +          error killing the client.<br>
>> +        </description><br>
>> +      </event><br>
>> +<br>
>> +  </interface><br>
>> +</protocol><br>
>> --<br>
>> 2.6.2<br>
>><br>
>> _______________________________________________<br>
>> wayland-devel mailing list<br>
>> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
>> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
><br>
><br>
</div></div></blockquote></div><div><br class="">Mariusz Ceier</div><div><br></div></div></div>