[PATCH 1/3 v4] wayland-server: Add API to control globals visibility

[Olivier Fourdan]

Hi Pekka,

> sorry for taking so long to reply.

Now it's my turn to apologize, I saw your email and then forgot about it!
 
> A recap from earlier emails as I understood them:
> 
> - This patch adds a callback in libwayland-server's wl_registry
>   implementation, that will be called every time a) libwayland-server
>   is about to send an advert of a global to a client, and b) when a
>   client tries to correctly bind a global interface, to determine if
>   that should actually happen. Case b) is needed in case a malicious
>   client guesses the global name and interface correctly.
> 
> - This does not actually have any significant consequences and it does
>   not close any "security holes" that would not be closable/closed
>   already otherwise. It is purely about trimming down the list of
>   globals per client. Essentially it's kind of like an ad hoc
>   implementation of namespaces for globals.
> 
> - It was said that this is quite different to Giulio's plans for
>   privileged/restricted interface negotiation [1].

I agree with all of the above :)

> I do like the simplicity and power of the design: a callback is simple,
> yet the API user (compositor) can do whatever it could ever imagine
> with it.
> 
> We could use this to replace all the existing private interface
> permission checks in Weston.
> 
> Let's think more about this proposal vs. Giulio's privileged interface
> negotiation. I believe the reasons why this cannot be used as a part
> for implementing Giulio's proposal is that to do the negotation, you
> have to create a wl_registry first to get access to the negotiation
> interface. If the negotiation succeeds, then the compositor would
> somehow have to send all the global ads that just became possible for
> the client. That would be quite awkward to implement with wl_registry
> in libwayland-server.
> 
> Revoking permissions for global interfaces that have already been bound
> to is another case wl_registry cannot easily deal with, even though we
> do have wl_registry.remove event that would be just perfect. The
> problem is the interface between libwayland-server and the compositor.
> 
> As much as I'd like to see a common solution to both features, it
> cannot happen with the globals filtering proposed in this patch, I
> believe.
> 
> However, I think it would be possible to avoid all need for globals
> filtering by developing Giulio's proposal. OTOH, it would be more code
> and more work for the simple cases where we do not need negotiation
> after creating the Wayland connection.
> 
> My main worry is that when someone develops Giulio's proposal into a
> standard, this feature will become redundant. I have no other reason to
> dislike this approach.
> 
> Have you looked at [1], what do you think of it?
> 
> I have made some negative comments in that thread, but afterwards I
> have come around a bit, thinking it might be a good approach the
> problems it aims to solve after all.

I think this is two different things, Giulio's authorizer protocol has a different use case, and will be very useful for example in the grabbing keyboard proposal I made some time ago, typically a given client tries to grab the keyboard, the compositor asks the user, etc.

This patch here is more about not even telling the client that we have a given protocol available, but once a protocol is advertised to a client, the authorizer protocol can be used to notify and get the user's consent.

> I'm very happy to see you wrote tests for the new API.
> 
> To get proper validation for the new libwayland-server API, I would
> like to see it used in Weston to replace all the existing privileged
> global checks. To make that fluent, I would like Weston to also use the
> recently added "new client created" callback to set up per-wl_client
> tracking data, a part of which would be flags telling which privileged
> interfaces can be bound or the special role of the client.
> 
> As the only serious request for this patch series, I would like the
> commit message to mention some more benefits we just figured out with
> Jonas in IRC:
> 
> - Hiding interfaces that expose compositor implementation details makes
>   it harder for clients to identify the compositor. Therefore clients
>   are a little less likely to develop compositor-specific workarounds
>   instead of reporting problems upstream.
> 
> - Hiding can be used to diminish the problems from missing namespacing:
>   if two compositors happen to use the same named global with different
>   interfaces for their special-purpose clients, the client expecting
>   the different interface would probably never see it advertised.
> 
> Therefore I think this would be a beneficial addition:
> Acked-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>

So, if I amend the commit message as above and rebase against current code, I can add your acked-by?

Cheers,
Olivier


> [1]
> https://lists.freedesktop.org/archives/wayland-devel/2015-November/025734.html
> continued in
> https://lists.freedesktop.org/archives/wayland-devel/2015-December/025884.html
>