[PATCH] Introduce the authorizer protocol
Mariusz Ceier
mceier+wayland at gmail.com
Tue Nov 24 09:07:34 PST 2015
Hi,
On 24 November 2015 at 17:35, Giulio Camuffo <giuliocamuffo at gmail.com>
wrote:
> 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.
>
>
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.
> > 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 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 ? ;)
I think something like wl_registry but for restricted interfaces only, may
be a better solution.
Also since authorizer is another global, it would have to be announced
before any restricted interface, right ?
That requirement probably should be added to description.
>
> > 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
> >
> >
>
Mariusz Ceier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151124/4a365ba5/attachment.html>
More information about the wayland-devel
mailing list