[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