Re: [PATCH] Introduce the authorizer protocol
On Wed, 2 Dec 2015 12:28:33 +0200 Giulio Camuffo wrote: > 2015-11-26 10:21 GMT+02:00 Pekka Paalanen : > > On Wed, 25 Nov 2015 17:39:25 +0100 > > Mariusz Ceier wrote: > > > >> Hi, > >> > >> On 25 November 2015 at 16:14, Pekka Paalanen wrote: > >> > >> > On Tue, 24 Nov 2015 18:07:34 +0100 > >> > Mariusz Ceier wrote: > >> > > >> > > Hi, > >> > > > >> > > On 24 November 2015 at 17:35, Giulio Camuffo > >> > > wrote: > >> > > > >> > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > >> > > > > >> > > > > 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. > >> > > >> > Why should we separate restricted interfaces in the registry level? Or > >> > at all? > >> > > >> > > >> Because binding restricted interface kills client and since interface > >> specification doesn't tell if that interface is restricted or not, binding > >> would be a gamble for client. Also to authorize the client to use of > >> restricted interface, authorizer object needs to be created - that means > >> restricted interfaces can't be bound before authorizer object is announced, > >> and that means restricted interfaces can't be announced before authorizer > >> is announced, unless client can bind them later (which I don't think is a > >> case). > > > > As said, all clients must be able to deal with arbitrary advertising > > orders. There is nothing hard with that, even toytoolkit supports it. > > Agreed. > > > > >> The interface specification needs to say whether it is restricted or > >> > not. If a compositor does not care about restricting it, it'll just > >> > always answer "yes." > >> > > >> > >> Even if interface specification would include information whether it's > >> restricted or not, that information would have to be included in protocol - > >> since later versions of protocol can become restricted. > > > > If later versions become restricted, that changes nothing here. Clients > > using earlier versions will bind an earlier version and avoid the > > security check. A client implementing support for the restricted version > > obviously also implements support for getting the authorization, > > because that is part of the spec. > > > > If you mean retroactively restricting, see below. > > > >> > When you design a new protocol extension, I can't imagine that you > >> > would not know if it needs to be restricted or not. Do you have any > >> > example to the contrary? > >> > > >> > >> I think it may be the case during development and even after it gets > >> stabilized. > >> It may be unrestricted at first, but then someone might find security bug > >> (in design) or request requiring privileged access could be added - in > >> these cases compositors probably would like to restrict access to that > >> interface. > >> In v1 of authorizer that would mean, that clients which assumed that > >> specific interfaces are unrestricted would be killed by compositor. > >> And in v2 authorizer clients would know that they need to send authorize > >> request first - since interface wouldn't be available in wl_registry but > >> only in wl_restricted_registry. > > > > Ok, that makes some sense, but I'm still skeptical. > > > > If there is an app using a global Foo, that is then discovered insecure > > and becomes retroactively restricted, it would no longer be advertised > > in the normal registry. If the app relied on Foo, it no longer works > > without changes. If Foo was optional for the app, the app continues to > > work without it, but getting it back would again require changes in the > > app to get it to look for it from the restricted registry. If it has > > code to look in the restricted registry, it could still be denied the > > authorization. > > However if an app can work even without the Foo global, or just wants > to display a nice user friendly dialog saying Foo is not available > instead of just dying, moving the global from wl_registry to > wp_restricted_registry would allow the app to realize Foo is not > available, while just making the global in wl_registry restricted > would mean the app would unknowingly try to bind it and it would get > killed. So i'd say the restricted registry is more app/user friendly > here. Right. The point is to stop advertising the old global in wl_registry. What you would do in addition to that is up for debate: would it be enough to just advertise it on a different name? There
Re: [PATCH] Introduce the authorizer protocol
2015-11-26 10:21 GMT+02:00 Pekka Paalanen : > On Wed, 25 Nov 2015 17:39:25 +0100 > Mariusz Ceier wrote: > >> Hi, >> >> On 25 November 2015 at 16:14, Pekka Paalanen wrote: >> >> > On Tue, 24 Nov 2015 18:07:34 +0100 >> > Mariusz Ceier wrote: >> > >> > > Hi, >> > > >> > > On 24 November 2015 at 17:35, Giulio Camuffo >> > > wrote: >> > > >> > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : >> > > > > 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. >> > >> > Why should we separate restricted interfaces in the registry level? Or >> > at all? >> > >> > >> Because binding restricted interface kills client and since interface >> specification doesn't tell if that interface is restricted or not, binding >> would be a gamble for client. Also to authorize the client to use of >> restricted interface, authorizer object needs to be created - that means >> restricted interfaces can't be bound before authorizer object is announced, >> and that means restricted interfaces can't be announced before authorizer >> is announced, unless client can bind them later (which I don't think is a >> case). > > As said, all clients must be able to deal with arbitrary advertising > orders. There is nothing hard with that, even toytoolkit supports it. Agreed. > >> The interface specification needs to say whether it is restricted or >> > not. If a compositor does not care about restricting it, it'll just >> > always answer "yes." >> > >> >> Even if interface specification would include information whether it's >> restricted or not, that information would have to be included in protocol - >> since later versions of protocol can become restricted. > > If later versions become restricted, that changes nothing here. Clients > using earlier versions will bind an earlier version and avoid the > security check. A client implementing support for the restricted version > obviously also implements support for getting the authorization, > because that is part of the spec. > > If you mean retroactively restricting, see below. > >> > When you design a new protocol extension, I can't imagine that you >> > would not know if it needs to be restricted or not. Do you have any >> > example to the contrary? >> > >> >> I think it may be the case during development and even after it gets >> stabilized. >> It may be unrestricted at first, but then someone might find security bug >> (in design) or request requiring privileged access could be added - in >> these cases compositors probably would like to restrict access to that >> interface. >> In v1 of authorizer that would mean, that clients which assumed that >> specific interfaces are unrestricted would be killed by compositor. >> And in v2 authorizer clients would know that they need to send authorize >> request first - since interface wouldn't be available in wl_registry but >> only in wl_restricted_registry. > > Ok, that makes some sense, but I'm still skeptical. > > If there is an app using a global Foo, that is then discovered insecure > and becomes retroactively restricted, it would no longer be advertised > in the normal registry. If the app relied on Foo, it no longer works > without changes. If Foo was optional for the app, the app continues to > work without it, but getting it back would again require changes in the > app to get it to look for it from the restricted registry. If it has > code to look in the restricted registry, it could still be denied the > authorization. However if an app can work even without the Foo global, or just wants to display a nice user friendly dialog saying Foo is not available instead of just dying, moving the global from wl_registry to wp_restricted_registry would allow the app to realize Foo is not available, while just making the global in wl_registry restricted would mean the app would unknowingly try to bind it and it would get killed. So i'd say the restricted registry is more app/user friendly here. > > So this would work like a per-client selective interface deprecation > assuming that clients support searching for globals from both > registries. > > It is a nice mechanism, but I have the feeling that this is a too > generic solution to a problem that is only hand-waving at this point. > > Continuing with the speculation, what if the authorization request > would need interface specific parameters? Interesting question. I'd say that if an interface needs that it should have some custom request to be used after the bind. I'm
Re: [PATCH] Introduce the authorizer protocol
On Wed, 25 Nov 2015 17:39:25 +0100 Mariusz Ceier wrote: > Hi, > > On 25 November 2015 at 16:14, Pekka Paalanen wrote: > > > On Tue, 24 Nov 2015 18:07:34 +0100 > > Mariusz Ceier wrote: > > > > > Hi, > > > > > > On 24 November 2015 at 17:35, Giulio Camuffo > > > wrote: > > > > > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > > > > > 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. > > > > Why should we separate restricted interfaces in the registry level? Or > > at all? > > > > > Because binding restricted interface kills client and since interface > specification doesn't tell if that interface is restricted or not, binding > would be a gamble for client. Also to authorize the client to use of > restricted interface, authorizer object needs to be created - that means > restricted interfaces can't be bound before authorizer object is announced, > and that means restricted interfaces can't be announced before authorizer > is announced, unless client can bind them later (which I don't think is a > case). As said, all clients must be able to deal with arbitrary advertising orders. There is nothing hard with that, even toytoolkit supports it. > The interface specification needs to say whether it is restricted or > > not. If a compositor does not care about restricting it, it'll just > > always answer "yes." > > > > Even if interface specification would include information whether it's > restricted or not, that information would have to be included in protocol - > since later versions of protocol can become restricted. If later versions become restricted, that changes nothing here. Clients using earlier versions will bind an earlier version and avoid the security check. A client implementing support for the restricted version obviously also implements support for getting the authorization, because that is part of the spec. If you mean retroactively restricting, see below. > > When you design a new protocol extension, I can't imagine that you > > would not know if it needs to be restricted or not. Do you have any > > example to the contrary? > > > > I think it may be the case during development and even after it gets > stabilized. > It may be unrestricted at first, but then someone might find security bug > (in design) or request requiring privileged access could be added - in > these cases compositors probably would like to restrict access to that > interface. > In v1 of authorizer that would mean, that clients which assumed that > specific interfaces are unrestricted would be killed by compositor. > And in v2 authorizer clients would know that they need to send authorize > request first - since interface wouldn't be available in wl_registry but > only in wl_restricted_registry. Ok, that makes some sense, but I'm still skeptical. If there is an app using a global Foo, that is then discovered insecure and becomes retroactively restricted, it would no longer be advertised in the normal registry. If the app relied on Foo, it no longer works without changes. If Foo was optional for the app, the app continues to work without it, but getting it back would again require changes in the app to get it to look for it from the restricted registry. If it has code to look in the restricted registry, it could still be denied the authorization. So this would work like a per-client selective interface deprecation assuming that clients support searching for globals from both registries. It is a nice mechanism, but I have the feeling that this is a too generic solution to a problem that is only hand-waving at this point. Continuing with the speculation, what if the authorization request would need interface specific parameters? > > > > > 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 ? ;) > > > > Clients do not go binding random globals without knowing the > > specification. > > > > Still s
Re: [PATCH] Introduce the authorizer protocol
Hi, On 25 November 2015 at 16:14, Pekka Paalanen wrote: > On Tue, 24 Nov 2015 18:07:34 +0100 > Mariusz Ceier wrote: > > > Hi, > > > > On 24 November 2015 at 17:35, Giulio Camuffo > > wrote: > > > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > > > > 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. > > Why should we separate restricted interfaces in the registry level? Or > at all? > > Because binding restricted interface kills client and since interface specification doesn't tell if that interface is restricted or not, binding would be a gamble for client. Also to authorize the client to use of restricted interface, authorizer object needs to be created - that means restricted interfaces can't be bound before authorizer object is announced, and that means restricted interfaces can't be announced before authorizer is announced, unless client can bind them later (which I don't think is a case). The interface specification needs to say whether it is restricted or > not. If a compositor does not care about restricting it, it'll just > always answer "yes." > Even if interface specification would include information whether it's restricted or not, that information would have to be included in protocol - since later versions of protocol can become restricted. > When you design a new protocol extension, I can't imagine that you > would not know if it needs to be restricted or not. Do you have any > example to the contrary? > I think it may be the case during development and even after it gets stabilized. It may be unrestricted at first, but then someone might find security bug (in design) or request requiring privileged access could be added - in these cases compositors probably would like to restrict access to that interface. In v1 of authorizer that would mean, that clients which assumed that specific interfaces are unrestricted would be killed by compositor. And in v2 authorizer clients would know that they need to send authorize request first - since interface wouldn't be available in wl_registry but only in wl_restricted_registry. > > > > 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 ? ;) > > Clients do not go binding random globals without knowing the > specification. > Still specification doesn't say which protocol is restricted and which is not. In v1 authorizer clients can't assume that specific interface is always unrestricted (it could become restricted in later version or compositor could implement different policy), so they would have to send authorize request for each interface they use. > > > I think something like wl_registry but for restricted interfaces only, > may > > be a better solution. > > I see no need for this. > > > 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. > > There is no such requirement. Clients *must* deal with arbitrary > announcements orders anyway. > > Except they would get killed for trying to bind restricted interface without sending authorize request - and they can't send it before getting authorizer object (in v1). So v1 introduces weak order here. > > Thanks, > pq > Mariusz Ceier ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce the authorizer protocol
On Tue, 24 Nov 2015 18:07:34 +0100 Mariusz Ceier wrote: > Hi, > > On 24 November 2015 at 17:35, Giulio Camuffo > wrote: > > > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > > > 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. Why should we separate restricted interfaces in the registry level? Or at all? The interface specification needs to say whether it is restricted or not. If a compositor does not care about restricting it, it'll just always answer "yes." When you design a new protocol extension, I can't imagine that you would not know if it needs to be restricted or not. Do you have any example to the contrary? > > > 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 ? ;) Clients do not go binding random globals without knowing the specification. > I think something like wl_registry but for restricted interfaces only, may > be a better solution. I see no need for this. > 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. There is no such requirement. Clients *must* deal with arbitrary announcements orders anyway. Thanks, pq pgpjto7lT5MTF.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] Introduce the authorizer protocol
2015-11-24 20:53 GMT+02:00 Derek Foreman : > 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 000..f10dd0e >> --- /dev/null >> +++ b/unstable/authorizer/authorizer-unstable-v1.xml >> @@ -0,0 +1,90 @@ >> + >> + >> + >> + >> +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. >> + >> + >> + >> + >> + 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. >> + >> + >> + >> + >> +Any currently ongoing au
Re: [PATCH] Introduce the authorizer protocol
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 000..f10dd0e > --- /dev/null > +++ b/unstable/authorizer/authorizer-unstable-v1.xml > @@ -0,0 +1,90 @@ > + > + > + > + > +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. > + > + > + > + > + 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. > + > + > + > + > +Any currently ongoing authorization request will outlive this object. > + > + > + > + > + > +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 > +composit
Re: [PATCH] Introduce the authorizer protocol
Hi, On 24 November 2015 at 17:35, Giulio Camuffo wrote: > 2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > > 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 > > 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 000..f10dd0e > >> --- /dev/null > >> +++ b/unstable/authorizer/authorizer-unstable-v1.xml > >> @@ -0,0 +1,90 @@ > >> + > >> + > >> + > >> + > >> +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 > >>
Re: [PATCH] Introduce the authorizer protocol
2015-11-24 18:16 GMT+02:00 Mariusz Ceier : > 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 > 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 000..f10dd0e >> --- /dev/null >> +++ b/unstable/authorizer/authorizer-unstable-v1.xml >> @@ -0,0 +1,90 @@ >> + >> + >> + >> + >> +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. >> + >> + >> + >> + >> + 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 c
Re: [PATCH] Introduce the authorizer protocol
Hi, How the clients will know: a) which interface is restricted and which is not ? b) that the compositor implements restricted interface ? should they be visible in the registry ? 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. Mariusz Ceier On 24 November 2015 at 16:16, 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? > > 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 000..f10dd0e > --- /dev/null > +++ b/unstable/authorizer/authorizer-unstable-v1.xml > @@ -0,0 +1,90 @@ > + > + > + > + > +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. > + > + > + > + > + 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. > + > + > + > + > +Any currently ongoing authorization request will outlive this > object. > + > + > + > + > + > +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 a
[PATCH] Introduce the authorizer protocol
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 000..f10dd0e --- /dev/null +++ b/unstable/authorizer/authorizer-unstable-v1.xml @@ -0,0 +1,90 @@ + + + + +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. + + + + + 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. + + + + +Any currently ongoing authorization request will outlive this object. + + + + + +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. + + + + + + + + +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
