Finding needle in haystack..

[Glynn Clements]

Carsten Haitzler (The Rasterman) wrote:

> > > The reason I asked the question I did was that one way to trickle that
> > > information through to the window manager was:
> > >   window manager looks up XID of window
> > >   from XID we someway lookup the socket in use on that window
> > >   from the socket we lookup process id
> > >   from process id we look at the command line arguments to find the file
> > 
> > If you just want the command line arguments, try the WM_COMMAND
> > property.  This property is supposed to contain the command line
> > arguments that were used to run the program that owns the window.
> > Unfortunately, I think it's deprecated.  On my system, xterm sets it but
> > GIMP does not.  You might have to modify applications to set it.
> 
> gimp does - gtk apps changed how they do it - they set it on the client leader
> window which doesnt get mapped/managed :) you can find it - but the wm command
> wont help much in this case. he needs to map open fd's to file paths - slight
> problem though is the app likely will open the file read it then close the file
> handle - not keep it open, so u will miss the open fd :(

AFAICT, that isn't what the OP is trying to do. He's talking about
getting the server's fd for the /tmp/.X11-unix socket through which
Xlib connects to the server, scanning /proc/<X-server-pid>/fd to get
the socket number, then scanning /proc/*/fd to find the client process
which is on the other end of the connection.

The problem with using window properties alone is that the information
can be forged; any client can set a property claiming that it has a
particular (trusted) PID.

If an XID can be reliably mapped to a server-side fd, the rest of the
process (reliably mapping that to a PID) is straightforward.

-- 
Glynn Clements <glynn at gclements.plus.com>