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 <[email protected]> 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 > _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
