Re: how to convert a window ID to a linux process ID?
On Wed, 2004-03-24 at 03:52, dave giffin wrote: I need to be able to tell which process a given window was created by. (Window ID=Process ID) On the server side, in os/access.c, is a function LocalClientCred() that you can use to get the UID and GID of a local client. This function could be extended to return the PID as well since the structure returned by the SO_PEERCRED sockopt has the PID in it. Take a look at it; there's already a bunch of _XTrans stuff dealing with this sort of thing. --Eamon Apparently, X servers don't know which process a client is, they just get a socket (b/c of X's network transparency). It has been suggested that I could run a program like netstat on the client machine(which in my case is the same machine running the server) to get a list of which sockets belong to which processes. Then, I need to get the ID of the foreign socket (socket ID on client end) from which a window was created. What would work well is if the socket ID and the client/window ID could be written to STDOUT or STDIN when the window is created. Then I can have a script read the server's STDOUT or STDIN and compare it to the list of socket IDs and process IDs from netstat on the client machine (which for my purposes is on the same machine as the server). MY PROBLEM: I don't know how to get XFree86 to write the socket ID and client ID when a window is created! Today, I was looking at the XFree86(4.3.0) source code for the first time and trying some different hacks to get the info I wanted to print. In xc/programs/Xserver/dix/dispatch.c, I found ProcCreateWindow and the ClientPtr structure. I was able to get X to print client-index and client-OsPrivate-fd when a new window was created. Which is what I want, except that the client index that is printed is always 2 and the socket ID is always 13. 13 is the ID of the socket that X listens on and I think 2 is the server client? What am I doing wrong? How can I print the Window ID and foreign/from socket ID of a client when a window is created? :) thanx PS: I'm thinking of making a sourceforge project to publish the XFree86 modification and some associated scripts so that others will be able to see which process created which window. How does the project name XTracer sound? __ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Generalizing the XCSecurity CheckAccess callback
I'm working on an extension for X as part of the Security-Enhanced Linux project. The XCSecurity extension has a callback function in the client structure that gets called whenever a resource lookup is done on behalf of the client. I'd like to add functionality to the XCSecurity extension to allow other extensions (e.g. mine) to register callbacks for this event. My plan is to add a CallbackListPtr to XCSecurity and functions for other extensions to use to add/remove callbacks to it. Then I just have to make sure the CheckAccess structure member gets called for all lookups (not just untrusted ones), and have that function call all the callbacks besides doing the XCSecurity stuff (checking the trustlevel and all that). Comments/critiques on this idea would be appreciated. -- Eamon Walsh [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Betr: Re: xfs install on RedHat machine
On Thu, 2003-10-16 at 13:24, Mike A. Harris wrote: Anyway, the check for /usr/X11R6/bin/X to determine wether or not to start xfs has been removed for quite a while now, as it makes it difficult for people to start xfs, who don't run an X server on the same machine and just want to use xfs for network font serving. It seems like the best way to do it would be to still do the check for /usr/X11R6/bin/X, but only if TCP is disabled. You'd have to grep the configuration file to find this out, though. Don't know if that's worth it. Yes, this will probably upset the people out there who don't want xfs to start up if they're not using an X server. As I said above though, people can't have it both ways as we can't read people's minds. The initscript can be disabled like any other system service, so people who install xfs from now on, will have it enabled by default (and it has TCP disabled also by default), and those who don't actually want to use it or need it, can disable it themselves as an end user configuration customization. I feel this makes life the easiest for the largest amount of users out there, and that's one of our goals. ;o) -- Eamon Walsh [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
