Bug 43091 - Third level chooser dysfunct in untrusted clients
Summary: Third level chooser dysfunct in untrusted clients
Alias: None
Product: xorg
Classification: Unclassified
Component: App/xkbcomp (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: low normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Whiteboard: 2011BRB_Reviewed
Depends on:
Reported: 2011-11-19 05:59 UTC by Lasse Kliemann
Modified: 2012-11-24 18:31 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Workaround in xkeyboard-config (982 bytes, patch)
2011-11-29 12:34 UTC, Andreas Wettstein
no flags Details | Splinter Review

Description Lasse Kliemann 2011-11-19 05:59:43 UTC
My keyboard layout makes use of a third level chooser to give additional meaning to certain keys, e.g.

  key <AD01> { [ q, Q, slash ] };

The third level chooser is defined like so (here the space bar):

  key <SPCE> { symbols[Group1] = [ ISO_Level3_Shift ] };

So when I press space and Q, I get '/'.

This works fine so far.

However, when I start an untrusted client, the third level chooser stops working (so pressing space and Q produces 'q', not '/'). Otherwise the layout is maintained.

The same happens when using xmodmap. For example, I have a file with the following content:

  keysym q = q Q slash
  keysym space = Mode_switch

I load it using xmodmap as a trusted client. Then create an untrusted cookie using

    xauth generate :0 . untrusted

and switch to a different user account (via su or whatever) with that cookie in ~/.Xauthority and start an xterm. The combination of space and Q then produces 'q' and no slash anymore.

When other changes are done, like for instance

  keysym q = q X slash

then these are available to the untrusted client, i.e., Shift-Q produces an 'X' in a trusted as well as an untrusted client.

I am using the latest release of each component from <ftp://ftp.x.org/pub/individual/>. But I remember the same or a similar problem being present in older releases as well. The latest known working release was 7.2.
Comment 1 Andreas Wettstein 2011-11-21 12:20:01 UTC
Additional observations: When the solution with two groups is used (the xmodmap approach), the third symbol is reachable from untrusted clients when pressing a key bound to ISO_Level3_Shift, but not when pressing a key bound to Mode_switch.  For trusted clients (with XKB support), it is the other way round.

When I dump the current map to an xkb-file:

  xkbcomp :0 test.xkb

then add a second group for keys with more then two symbols, map a key to Mode_switch, and, most importantly add

  group 2 = AltGr;

to xkb_compatibility, and load up the modified file:

  xkbcomp test.xkb :0

then Mode_switch acts as desired, for both trusted and untrusted clients. The effect of Mode_switch as reported by xev:

client    ! Without group 2 = AltGr ! With group 2 = AltGr !
trusted   ! Sets second group       ! Sets second group    !
untrusted ! no effect               ! Sets Mod5            !

So, the problem seems to be that the group compatibly map as described in section 12.1 of "The X Keyboard Extension: Protocol Specification" does not work properly. 

Why it does not work, I do not understand. xkeyboard-config in compat/basic already contains "group 2 = AltGr".  Also, Mod5 is bound to Mode_switch in the modifier_map, and AltGr is associated to Mod5.

For the time being, the problem can be worked around as described above, or by using both a second group and a third level that both contain the third symbol, and switching to the additional symbol using ISO_Level3_Shift.
Comment 2 Andreas Wettstein 2011-11-29 12:34:38 UTC
Created attachment 53959 [details] [review]
Workaround in xkeyboard-config

Just a workaround, the bug is in xkbcomp.
Comment 3 Andreas Wettstein 2011-12-02 12:13:30 UTC
Submitted a patch for xkbcomp: http://patchwork.freedesktop.org/patch/8146/
Comment 4 Lasse Kliemann 2011-12-04 00:24:29 UTC
(In reply to comment #3)
> Submitted a patch for xkbcomp: http://patchwork.freedesktop.org/patch/8146/

This patch has solved the problem for me. Thank you!
Comment 5 Daniel Stone 2011-12-06 04:13:38 UTC
Committed to xkbcomp, thanks.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.