[PATCH] Introduce the authorizer protocol

[Pekka Paalanen]

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?

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151125/8cdeed0c/attachment.sig>