[PATCH] Introduce the authorizer protocol

[Mariusz Ceier]

Hi,

On 25 November 2015 at 16:14, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Tue, 24 Nov 2015 18:07:34 +0100
> Mariusz Ceier <mceier+wayland at gmail.com> wrote:
>
> > 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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151125/887156d7/attachment-0001.html>