Hiding keyboard state

Keith Packard keithp at keithp.com
Tue Jun 21 07:17:12 UTC 2016

Antoine Martin <antoine at nagafix.co.uk> writes:

> This may cause us problems with xpra: we use XQueryKeymap to see which
> keys are down when trying to synchronize remote and local keyboard
> state, in particular for the modifiers.

The new query code returns the current state of the keyboard as known to
each client, so you get all of the keys which your client might have
received events about, including the full key state on enter events.

> The KeymapNotify handling in this patch just copies the new keymap,
> can't that be used to see which keys are pressed? Or does setting a new
> keymap also reset pressed keys?

Yes, you receive the full state of the keyboard whenever you receive
focus, and this patch doesn't change that. The goal is to eliminate the
ability to poll the keymap rapidly to see what *other* clients are

> The most important requirement we have is to be able to force unset all
> the modifiers when a new client connects, so maybe we can just set a new
> keymap every time to achieve that?

Inside the server you can do whatever you like, as usual.

> Since the actual keyboard state is still global and not per application,
> what happens if:
> * another app presses Shift_R, setting the "shift" modifier,
> * we query the keymap and find that the "shift" modifier is not set,
> * we press some other key (say "a") via XTest, expecting that
> applications will see "a" but they may in fact see "(shift)a", right?


> At present, we can spot that "shift" is (un)set and toggle it as needed,
> using the correct key too (Shift_L vs Shift_R), will this no longer be
> the case?

To work without knowing the state of the keys, you would simply need to
always send events to set the modifiers to the appropriate state.

> I understand the motivation though.. And we may be ok for most use
> cases, but is there a chance of making this optional somehow?
> A fair number of users rely on xpra + virtualization for application
> isolation and therefore the security of the X11 keyboard within the
> server is of no concern to them, but "correct" keyboard handling is.

I've also started working on a more complete inter-client isolation
notion where we have privileged clients that have access to global
server state (like the testing extensions). With this, we'd be able to
have your clients run with that special ability and have that expose the
global keymap instead of the per-client one.

> From a later reply to this thread:
>> Alternatively, we could restrict this request to "special"
> applications using the technique I've outlined for access to the testing
> extensions.
> Is this the "Disabling RECORD by default" thread or another?

Yes, of course that subject isn't accurate anymore as we need to disable
all testing extensions and a bunch of other global server state as well.

Thanks for helping think about this stuff; the goal is to provide
reasonable security while not breaking too many things.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 810 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160621/2df11803/attachment.sig>

More information about the xorg-devel mailing list