[PATCH] Introduce the authorizer protocol
Derek Foreman
derekf at osg.samsung.com
Tue Nov 24 10:53:10 PST 2015
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.
> 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.
Will we have privileged interfaces that a client would use if available
but the client can still proceed without?
> + </event>
> +
> + </interface>
> +</protocol>
>
More information about the wayland-devel
mailing list