Hiding keyboard state

[Antoine Martin]

On 21/06/16 09:17, Keith Packard wrote:
> 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
> receiving.
> 
>> 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?
> 
> Yes.
> 
>> 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.
For the sake of argument, we have encountered a number of applications
that respond to any key event (including modifiers) and so we have had
to work extra hard to try to minimize unnecessary XTest key events.
(handling AltGr with MS Windows client comes to mind)

But I don't think this is a huge issue for us anyway because we don't
want to support simultaneous input from non-xpra clients, and if
applications modify the keyboard state programmatically.. things are
likely to get out of sync no matter what we do.

>> 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.
Just a thought: could this be tied somehow with selection ownership?
A window manager would be expected to have more privileged access, and
this is usually arbitrated through selections.

>> 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.
Excellent, we'll be happy to test any security changes, if anything to
ensure that it doesn't break our stuff too much!

Cheers
Antoine


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160707/dc4c0323/attachment.sig>