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

[Pekka Paalanen]

On Fri, 22 Jun 2018 20:00:00 +0200
Dorota Czaplejewicz <dorota.czaplejewicz at puri.sm> 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.

Hi,

that is not exactly true. Now wayland-scanner just skips checking any
referenced enums that are not defined in the current XML file. It does
not make lookups in other XML files.


> ---- 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).

Errors will remain unrecoverable because they will always cause a
disconnection.

What is being worked on is avoiding the abort in the few yet unhandled
loew-level failure cases like implicit flush, so that the app can at
last clean up and save what it was doing, or maybe even reconnect if it
really wants to.

Protocol errors should not cause an abort() already.

> > 
> > 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?

No, protocol errors are always fatal to the Wayland connection, which
means the client gets disconnected and "destroyed". The application
process may continue though and even attemp to reconnect, but that
should not be relied upon in protocol design. So from protocol design
perspective, protocol errors are always unrecoverable.

The idea is that when a protocol error happens, it may invalidate
further requests made by the client and it almost always implies that
the server and the client no longer agree on the protocol state. Hence,
keeping the connection would be an equally good idea to continuing a
process after receiving a SIGSEGV.

> 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.

Indeed, one cannot use protocol errors for graceful rejection.

> 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?
> 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?

The intention is for one application to use one connection, but nothing
forbids using multiple connections. Multiple connection are usually
impractical, though. If the client was connected with WAYLAND_SOCKET (as
opposed to WAYLAND_DISPLAY), the client probably won't have the means
to reconnect or open additional connections.

Wayland's isolation between clients means that one cannot refer to a
Wayland object of one connection in another connection. It does not
matter if it's the same process or thread, if it's a separate
connection it is isolated.

There is currently no agreed mechanism to see if an interface is
allowed for the client or if it is even a privileged interface.

Giulio Camuffo at least had a proposal for advertising privileged
interfaces with graceful deny. Authenticating clients OTOH continues to
be an unsolved issue in general, I believe.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20180625/b27da1de/attachment.sig>