[PATCH 0/3] xserver: Client ID tracking

Mark Kettenis mark.kettenis at xs4all.nl
Tue Aug 31 13:56:45 PDT 2010


> Date: Tue, 31 Aug 2010 11:35:31 +0300
> From: =?ISO-8859-1?Q?Rami_Ylim=E4ki?= <rami.ylimaki at vincit.fi>
> 
> >> These patches add a simple framework for determining client related
> >> IDs such as PID and process name within X server. After these changes
> >> have been reviewed and accepted, the XRes extension will be modified
> >> to use the framework and provide client ID information for clients
> >> with a new protocol request.
> > How useful is this really, given that information from remote clients
> > isn't available, or at least cannot be trusted?
> 
> We have used this kind of code repeatedly in X server to identify local 
> clients that are behaving badly either by allocating too much memory and 
> resources in the server or by executing deprecated requests. Maintaining 
> private code to do this simply doesn't make sense anymore. Having the 
> code in X server by default would speed up development and debugging 
> time for us and also ease our maintenance burden.
> 
> We want to make also it possible to identify local clients outside of X 
> server. That's why we need a new request to query the PID information 
> reliably. It should be possible to easily track down problems on a 
> release version of a distribution without having to recompile a debug 
> version of X server first. Ultimately we want to use cnee to identify 
> clients that are executing deprecated requests and xrestop to identify 
> clients allocating too much resources. Currently there is no reliable 
> way to do this.
> 
> You are right in that we mainly care about local clients, because in 
> practice on our system all clients will be local. But I think that 
> having a good way to identify local clients is still very important even 
> though we wouldn't be able to reliably identify remote clients. We don't 
> mind if information about clients can't be trusted in a rogue 
> environment, because the framework would be used mainly to improve the 
> overall system quality and as an development aid, not as a secure client 
> framework for finding out which clients are trusted.

Fair enough; thanks for the explanation.


More information about the xorg-devel mailing list