Finding needle in haystack..

[Carsten Haitzler (The Rasterman)]

On Mon, 11 Sep 2006 17:32:29 -0700 "Thomson, David-P63356"
<David.Thomson at gdc4s.com> babbled:

> Thanks for all your comments,
> 
> I wish I could tell you all exactly what I need and why but I'm limited
> in what I can say.  I may not actually need an answer to the original
> question I posted if another solution works better.  Here's the most I
> think I can get away with:
> 
> We are editing a window manager to make it selinux "label-aware".  We
> want to color the window of "an app", we'll pretend it's Gimp, based on
> the security level of the document it wants to open.  The window manager
> therefore needs insight into what documents (not executables) are being
> launched in it's windows.  
> 
> 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
> This is hairy, nasty, and inherently pretty insecure but at the moment
> it's just to prove we can change an selinux label and have the border
> change color when re-launched.
> 
> The other way that was proposed is to modify the source of the
> application to pass the document information to a third party which the
> modified window manager can access.

why didn't you say this to start with! much better ways exist! let me start
with a few

1. _NET_WM_PID property - you can get the pid of the process owning that app (if
its a local process - if not u can  use the wm machine property and go over to
the src system) and then you can poke around in the process itself. evil- but
possible. modern apps that use gtk or qt (gnome or kde) set this property.
openoffice does too.
2. if this isn't set - you can have fun with ld_preload games to FORCE IT TO BE
SET (or patch xlib that you use).

code for this is shipped with e17 (preload hack) but disabled currently as it
causes problems with some apps on some systems.

cvs -d :pserver:anonymous at anoncvs.enlightenment.org:/var/cvs/e login
(empty password)
cvs -z3 -d :pserver:anonymous at anoncvs.enlightenment.org:/var/cvs/e co e17
cd e17/apps/e/src/preload

it sets proeprties private to e17 itself- but the same principle - you can just
force it to set a wm pid property anyway -and anything else you want to set for
tracking processes owning that window. :)

this also assumes that the process is launched by the wm (thus it can set up
the preload). there is code in e17 that does so - but disabled. if you use
something else, then it is the job of that launcher to set up the preload... or
hack xlib  :)

> Any thoughts?
> 
> David Thomson
> 
> -----Original Message-----
> From: Jay.Cotton at Sun.COM [mailto:Jay.Cotton at Sun.COM] 
> Sent: Monday, September 11, 2006 5:10 PM
> To: Alan Coopersmith
> Cc: Thomson, David-P63356; xorg at lists.freedesktop.org
> Subject: Re: Finding needle in haystack..
> 
> Alan Coopersmith wrote:
> 
> > Thomson, David-P63356 wrote:
> >
> >> Developers,
> >>
> >> Could someone please hear me out and shoot me a quick response, I
> find
> >> these developer mailing lists are pretty segregated and people only
> >> respond to posts that deal exclusively with the work they are doing. 
> >> Short story:  I am doing work for "No Such Agency" .  Our project
> would
> >> like a nice clean way of getting the socket number associated with
> the
> >> XID of a window.  Is there a function that returns this info?  If not
> >> I'll be making such a function.  If I do, I'll be looking for where
> the
> >> window id's/socket number correlation is stored/modified.  
> >
> >
> > The X server stores a file descriptor id for each client (not window)
> in
> > a table internally, but those are not necessarily sockets, and don't
> have
> > any meaning outside that process and the kernel's fd table for that 
> > process,
> > so I'm not sure what you're looking for.  What are you referring to as
> > a "socket number"?
> >
> There is a strong relationship between the FD and the client number
> (XID).
> So, since you can track back to the client connection (Alans' Dtrace 
> code) you
> should be able to trudge through the connection table and find the 
> socket number.
> If there is one.  Remember that most clients don't have sockets since 
> they are
> local to the server. 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)