[PATCH] Introduce the authorizer protocol

Giulio Camuffo giuliocamuffo at gmail.com
Tue Nov 24 08:35:17 PST 2015


2015-11-24 18:16 GMT+02:00 Mariusz Ceier <mceier+wayland at gmail.com>:
> Hi,
>   How the clients will know:
> a) which interface is restricted and which is not ?

It doesn't, but does it need to know it? It can still ask for
authorization even if the interface is not.

> b) that the compositor implements restricted interface ? should they be
> visible in the registry ?

Well, they are normal globals so they will are available in the
registry. If needed, this interface could
send out a list of the restricted ones, but i'm not sure it is.

>
> If the client would like to use many restricted interfaces, it would have to
> issue multiple authorize requests - probably causing compositor to show many
> popups/notifications. I think it would be better to send list of interfaces
> and receive back a list of interfaces for which access was granted instead.

That's a valid point... i don't think wl_array works for strings
though, so instead i'd add a way to group requests together.


--
Giulio

>
> Mariusz Ceier
>
>
> On 24 November 2015 at 16:16, Giulio Camuffo <giuliocamuffo at gmail.com>
> wrote:
>>
>> This new extension is used by clients wanting to execute priviledged
>> actions such as taking a screenshot.
>> The usual way of granting special priviledged to apps is to fork and
>> exec them in the compositor, and then checking if the client is the
>> known one when it binds the restricted global interface. This works
>> but is quite limited, as it doesn't allow the compositor to ask the
>> user if the app is trusted, because it can't wait for the answer in
>> the bind function as that would block the compositor.
>> This new protocol instead allows the answer to come after some time
>> without blocking the compositor or the client.
>> ---
>>
>> For reference, i've implemented this in orbital[0] and it's used by
>> the screenshooter tool[1]. The name is different but it works exaclty
>> the same as this one.
>> One thing missing is how the revoke authorization, if even want/need it?
>>
>> 0:
>> https://github.com/giucam/orbital/blob/master/src/compositor/authorizer.cpp
>> 1:
>> https://github.com/giucam/orbital/blob/master/src/screenshooter/main.cpp#L301
>>
>>
>>  Makefile.am                                    |  1 +
>>  unstable/authorizer/authorizer-unstable-v1.xml | 90
>> ++++++++++++++++++++++++++
>>  2 files changed, 91 insertions(+)
>>  create mode 100644 unstable/authorizer/authorizer-unstable-v1.xml
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index a32e977..bfe9a6a 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -5,6 +5,7 @@ unstable_protocols =
>> \
>>         unstable/text-input/text-input-unstable-v1.xml
>> \
>>         unstable/input-method/input-method-unstable-v1.xml
>> \
>>         unstable/xdg-shell/xdg-shell-unstable-v5.xml
>> \
>> +       unstable/authorizer/authorizer-unstable-v1.xml
>>         $(NULL)
>>
>>  nobase_dist_pkgdata_DATA =
>> \
>> diff --git a/unstable/authorizer/authorizer-unstable-v1.xml
>> b/unstable/authorizer/authorizer-unstable-v1.xml
>> new file mode 100644
>> index 0000000..f10dd0e
>> --- /dev/null
>> +++ b/unstable/authorizer/authorizer-unstable-v1.xml
>> @@ -0,0 +1,90 @@
>> +<?xml version="1.0" encoding="UTF-8"?>
>> +<protocol name="authorizer_unstable_v1">
>> +
>> +  <copyright>
>> +    Copyright © 2015 Giulio Camuffo.
>> +
>> +    Permission to use, copy, modify, distribute, and sell this
>> +    software and its documentation for any purpose is hereby granted
>> +    without fee, provided that the above copyright notice appear in
>> +    all copies and that both that copyright notice and this permission
>> +    notice appear in supporting documentation, and that the name of
>> +    the copyright holders not be used in advertising or publicity
>> +    pertaining to distribution of the software without specific,
>> +    written prior permission.  The copyright holders make no
>> +    representations about the suitability of this software for any
>> +    purpose.  It is provided "as is" without express or implied
>> +    warranty.
>> +
>> +    THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
>> +    SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
>> +    FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
>> +    SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
>> +    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
>> +    AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
>> +    ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
>> +    THIS SOFTWARE.
>> +  </copyright>
>> +
>> +  <interface name="zwp_authorizer_v1" version="1">
>> +    <description summary="authorize clients to use certain interfaces">
>> +      This global interface allows clients to ask the compositor the
>> +      authorization to bind certain restricted global interfaces.
>> +      Any client that aims to bind restricted interfaces should first
>> +      request the authorization by using this interface. Failing to do
>> +      so will result in the compositor sending a protocol error to the
>> +      client when it binds the restricted interface.
>> +
>> +      The list of restricted interfaces is compositor dependant, but must
>> +      not include the core interfaces defined in wayland.xml. However, if
>> +      an authorization request is done for a non-restricted interface the
>> +      compositor must reply with a grant.
>> +    </description>
>> +
>> +    <request name="destroy" type="destructor">
>> +      <description summary="destroy this zwp_authorizer_v1 object">
>> +        Any currently ongoing authorization request will outlive this
>> object.
>> +      </description>
>> +    </request>
>> +
>> +    <request name="authorize">
>> +      <description summary="authorize a global interface">
>> +        The authorize request allows the client to ask the compositor the
>> +        authorization to bind a restricted global interface. The newly
>> +        created zwp_authorizer_feedback_v1 will be invalid after the
>> +        compositor sends either the granted or denied event so the client
>> +        is expected to destroy it immediately after.
>> +      </description>
>> +      <arg name="id" type="new_id" interface="zwp_authorizer_feedback_v1"
>> summary="the new feedback object"/>
>> +      <arg name="global" type="string" summary="the global interface the
>> client wants to bind"/>
>> +    </request>
>> +    </interface>
>> +
>> +    <interface name="zwp_authorizer_feedback_v1" version="1">
>> +      <description summary="feedback for an authorization request">
>> +        A zwp_authorizer_feedback_v1 object is created by requesting
>> +        an authorization with the zwp_authorizer_v1.authorize request.
>> +        The compositor will send either the granted or denied event based
>> +        on the system and user configuration. How the authorization
>> process
>> +        works is compositor specific, but a compositor is allowed to ask
>> +        for user input, so the client must not assume the reply will come
>> +        immediately.
>> +      </description>
>> +
>> +      <event name="granted">
>> +        <description summary="the authorization was granted">
>> +          The authorization was granted. The client can now bind the
>> restricted
>> +          interface.
>> +        </description>
>> +      </event>
>> +
>> +      <event name="denied">
>> +        <description summary="the authorization was denied">
>> +          The authorization was denied. The client is not allowed to bind
>> the
>> +          restricted interface and trying to do so will trigger a
>> protocol
>> +          error killing the client.
>> +        </description>
>> +      </event>
>> +
>> +  </interface>
>> +</protocol>
>> --
>> 2.6.2
>>
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>


More information about the wayland-devel mailing list