[PATCH v3 wayland-protocols] virtual-keyboard: Add new virtual keyboard protocol

Sun Jun 24 09:46:50 UTC 2018

On 2018/6月/22 08:00, Dorota Czaplejewicz wrote:
> On Fri, 22 Jun 2018 12:36:16 -0400
> Simon Ser <contact at emersion.fr> wrote:
> 
> > On June 22, 2018 4:20 PM, Dorota Czaplejewicz <dorota.czaplejewicz at puri.sm> wrote:
> > > Provides the ability to emulate keyboards by applications. Complementary to input-method protocol.
> > >
> > > The interface is a mirror copy of wl_keyboard, with removed serials, and added seat binding.
> > > ---
> > > Hi,
> > >
> > > this patch is another improvement to the previously sent virtual keyboard protocol. Changes compared to v2:
> > >
> > > - readded enum names
> > > - removed suggestion to listen to modifiers
> > > - clarified untrusted client behaviour
> > > - added destructor on virtual_keyboard_manager
> > > - fixed text wrapping
> > >
> > > First off, the new version of wayland-scanner looks up enums found in other xml files, so the textual reference are gone and actual enum values are used.
> > >
> > > Secondly, there was a suggestion that if the client wants to know global modifiers, it should listen to wl_keyboard.modifiers. In reality, this can only be done when the client has keyboard focus. I decided to remove this suggestion.
> > >
> > > Clarified that create_virtual_keyboard must error out with unauthorized when an untrusted client connects. That doesn't preclude making the whole virtual_keyboard_manager interface unavailable when the client is determined as untrusted ahead of time.
> > >
> > > Lastly, added a missing destructor as per Simon Ser's suggestion.
> > >
> > > I hope that we're getting closer to perfect with this revision! As usual, feedback is welcome.
> > >
> > > Cheers,
> > > Dorota Czaplejewicz  
> > 
> > Hi,
> > 
> > Thanks for this updated version. A few comments below.
> > 
> ---- snip ----
> > > +
> > > +  <interface name="zwp_virtual_keyboard_manager_v1" version="1">
> > > +    <description summary="virtual keyboard manager">
> > > +      A virtual keyboard manager allows an application to provide keyboard
> > > +      input events as if they came from a physical keyboard.
> > > +
> > > +      If the compositor enables a keyboard to perform arbitrary actions, it
> > > +      should prevent untrusted clients from using this interface.
> > > +    </description>
> > > +
> > > +    <enum name="error">
> > > +      <entry name="unauthorized" value="0"
> > > +        summary="client not authorized to use the interface"/>
> > > +    </enum>  
> > 
> > This is more of a general metaphorical question than anything else: I wonder how
> > we should handle unauthorized clients, and if adding an error for them is a good
> > idea. Generally errors are meant for protocol violations: it's clear from the
> > protocol spec that e.g. sending a request with a negative value will trigger a
> > protocol error. Also, errors are unrecoverable, they abort the whole client
> > (though this is being worked on).
> > 
> > So here we use an error, and the conditions in which the error is sent are
> > implementation-defined. I wonder if there's a better way to handle this
> > situation?
> > 
> Speaking from a position of someone without a lot of Wayland experience: are Wayland errors meant to be recoverable by a client? It's obvious that if an application doing its primary task and then trying to use a restricted protocol as a secondary action crashes, that's undesireable.
> 
> As a more concrete example, an automation application may use e.g. DBus API to automate tasks, and display a window to control it. It may request a virtual keyboard to extend its possibilities, but it shouldn't suddenly stop working if it's refused by the compositor.
Currently the errors will result in an abort() by libwayland. There is a patch 
series that changes this, but it will still be fatal on the wayland connection 
as far as I'm aware. Which isn't quite as bad, but can still be a problem, if 
an application uses the same wayland connection for more than one feature.
> 
> That brings me to the question: should applications using restricted protocols create additional connections which may be broken and recovered from individually or should they rather use one connection?
I'd personally prefer single fat connection. Mostly because it makes some 
bookkeeping easier, and some of the things I want to try out from the 
compositor side work better this way. But it's more robust (or rather will be) 
to have multiple, especially if one feature is expected to result in errors 
for some reason (the only expected errors should be design mistakes IMO, but 
this might still happen)

> If the latter is required for some use cases, then authorization and probing/graceful rejection should be specified inside protocols.  Unfortunately, I'm not sure where to look for examples. Perhaps chat applications where screen sharing may be decided ad hoc check the marks?
This is a good usecase for defaulting to query the user IMO. The client would 
try to access the interface at that time (either bind late, or have the first 
real request) at which point the compositor shows the user a query window that 
asks for permission to be granted for the client in question.
IFF the client uses the fat connection, it could display the window of the 
client in the query/highlight it on screen.
In the split case, this isn't quite as easy.

If the application is trusted with screen contents in general, it can be 
started by the compositor with a pre-prepared wl_client (with WAYLAND_SOCKET 
and socketpair()) which is associated with permissions. Sadly this fails hard 
with the multi-connection approach, since only the first client will be 
recognised.

Another approach I want to try out (but haven't gotten around to yet, due to 
lack of immediate usecase) would be to use dedicated WAYLAND_DISPLAY sockets 
for some applications (protected by container mountpoints) and have
permissions bound to all clients accepted over that socket.

The socket/client based approach has the advantage, that we can use the 
wl_display_set_global_filter to prevent clients binding to privileged 
protocols in the first place. On the other hand, sending the query on demand 
is quite a bit more flexible, but can result in odd cases, where a client 
creates an object (which can't fail) but the compositor doesn't give 
permissions to it.

> 
> > > +    <request name="create_virtual_keyboard">
> > > +      <description summary="Create a new virtual keyboard">
> > > +        Creates a new virtual keyboard associated to a seat.
> > > +
> > > +        If an untrusted client issues this request, it should receive the
> > > +        unauthorized error in return.
> > > +      </description>
> > > +      <arg name="seat" type="object" interface="wl_seat"/>
> > > +      <arg name="id" type="new_id" interface="zwp_virtual_keyboard_v1"/>
> > > +    </request>
> > > +
> > > +    <request name="destroy" type="destructor">
> > > +      <description summary="destroy the virtual keyboard manager object"/>  
> > 
> > This description should probably specify what happens to keyboards created with
> > the manager when the manager is destroyed. A common practice is not to destroy
> > objects when the manager is destroyed, so that one can easily create the
> > manager, use the factory request, and immediately destroy the manager (see e.g.
> > wl_subcompositor).
> 
> This is an oversight and will be fixed.
> > 
> > > +    </request>
> > > +  </interface>
> > > +</protocol>
> > > --
> > > 2.14.4
> > >
> > > _______________________________________________
> > > wayland-devel mailing list
> > > wayland-devel at lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/wayland-devel  
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 

> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180624/77784745/attachment.sig>