[PATCH xserver] os: Treat ssh as a non-local client (v3)

Michel Dänzer michel at daenzer.net
Tue Jan 12 17:59:23 PST 2016

On 13.01.2016 03:43, Adam Jackson wrote:
> On Thu, 2015-12-17 at 16:41 +0900, Michel Dänzer wrote:
>> From: Adam Jackson <ajax at redhat.com>
>> By the time we get to ComputeLocalClient, we've already done
>> NextAvailableClient → ReserveClientIds → DetermineClientCmd (assuming
>> we're built with #define CLIENTIDS), so we can look up the name of the
>> client process and refuse to treat ssh's X forwarding as if it were
>> local.
>> v2: (Michel Dänzer)
>>     * Only match "ssh" itself, not other executable names starting with
>>       that prefix.
>>     * Ignore executable path for the match.
>> v3: (Michel Dänzer)
>>     * Use GetClientCmdName (Mark Kettenis)
>>     * Perform check on Windows as well, but only ignore path on Cygwin
>>       (Martin Peres, Emil Velikov, Jon Turney)
> But this doesn't work reliably, which is why I used strncmp in the
> first place. See my original test report:
> http://lists.freedesktop.org/archives/xorg-devel/2015-December/048164.html

I somehow missed that before, sorry.

Looks like this could be addressed by cutting of the colon and anything
after it using something like strtok(_r)?

> Note that cmdname is not always "ssh".

Indeed, that's one of the points which prompted my changes. E.g. it can
contain the executable path, which is stripped off with basename. That
might not work too well either with your example above without cutting
off at the colon.

> Are we honestly concerned that some client's name is prefixed with
> "ssh" and _isn't_ ssh or something acting like it?

That seems quite plausible. Debian is already shipping many more
executables starting with "ssh", that number will probably only increase
with time. Maybe none of them need DRI2/3 yet, but we shouldn't lightly
rely on that being the case for any future ones.

Earthling Michel Dänzer               |               http://www.amd.com
Libre software enthusiast             |             Mesa and X developer

More information about the xorg-devel mailing list