[PATCH] Introduce the authorizer protocol
Giulio Camuffo
giuliocamuffo at gmail.com
Wed Nov 25 05:49:45 PST 2015
2015-11-24 20:53 GMT+02:00 Derek Foreman <derekf at osg.samsung.com>:
> On 24/11/15 09:16 AM, Giulio Camuffo 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?
>
> What happens if the privileged interface can only be bound by one app at
> a time? (like a virtual keyboard, or weston's screen shooter that is
> triggered by a key bind)
>
> I think we'd need a revocation for situations like that, but I can't
> think of a way for it to not be painful.
We can do something like removing the global for the client and ignore
any request coming, but i don't think we can kill the client if it
keeps using it, because we don't know when the remove event was
received.
>
>> 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 ++++++++++++++++++++++++++
>
> Maybe also add a README file?
>
>> 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
>
> Ask the compositor _for_ authorization?
>
>> + 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.
>
> Seems like this could work for the stuff weston launches with privilege,
> like screenshooter and virtual keyboard. The implementation defined
> authorization would be the pid check.
>
> Cool.
>
>> + </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>
>
> I do wonder what a client could ever productively do in response to
> this. Trying again would be hugely annoying to users.
The compositor could either ignore authorization requests after the
first one (maybe for a certain amount of time) or killing the client,
but i'm not sure this latter option is very good. The user could
change the configuration so to allow it, and that would mean the
client needs to be restarted for the change to work.
>
> Will we have privileged interfaces that a client would use if available
> but the client can still proceed without?
Not sure... but so what are you suggesting, that the client should be
killed instead of having this denied event? I don't think that's a
good idea, it wouldn't allow the client to display a user dialog or
something explaining the problem.
--
Giulio
>
>> + </event>
>> +
>> + </interface>
>> +</protocol>
>>
>
More information about the wayland-devel
mailing list