Disabling RECORD by default

Keith Packard keithp at keithp.com
Wed Jun 15 06:41:19 UTC 2016

Peter Hutterer <peter.hutterer at who-t.net> writes:

> but note that syndaemon is a common user of RECORD, if it is disabled we
> fall back to regular querying of the keyboard state with all its
> drawbacks (unnecessary wakeups, missing of some key events, etc.)

Ok, I'm back revisiting this and have some new ideas.

First, we need to disable *all* of the testing extensions by default;
XTEST allows you to synthesize "real" keyboard events, and push random
input to applications. Matthew Garrett posted a fine demo of this

However, this really sucks as these extensions are awfully useful, both
for testing (meh), but more importantly, for accessibility. So, not
having access to them in the X server means not having a bunch of
accessibility. Not going to happen.

So, we need to have access to these extensions, but only for
applications that need it. We can make those setuid/setgid to some
suitable user or group and then just have the X server restrict access
based on the clients effective uid/gid values.

The alternative would be to use separate X authorization data, but
unless that is protected in the file system from access by the normal
user, it offers no actual security. Hence, any program needing the
'magic' X authorization data would need to be setuid/setgid anyways. So
we might as well simplify life by just directly checking for the special
uid or gid.

I think a special gid is probably the right idea; it means the
application would still be running as the current user, and hence able
to access the Xauthority file and read/write files owned by the user.

We can use this to protect lots of pieces of the system, from GetImage
to window properties.

-------------- 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/20160614/b522d9cd/attachment-0001.sig>

More information about the xorg-devel mailing list