On Wed, Jul 24, 2019 at 01:34:37AM +0100, Carsten Haitzler wrote:
> On Tue, 23 Jul 2019 13:57:01 -0700 x...@pengaru.com said:
> > Hello folks,
> >
> > I'd like to propose that Xorg set the _NET_WM_PID property on new
> > windows for local clients @ window create time whenever possible.
> >
> > This is something I added localy years ago to more reliably have this
> > property set with uncooperative clients that didn't set it. My window
> > manager integrates client process monitoring and relies on this property
> > for acquiring the PID of connected clients.
> >
> > At the time, it was just a few X clients that were problematic, stuff
> > like xpdf and other smaller programs using less popular toolkits or no
> > toolkit at all. It wasn't such a big deal, so I promptly forgot about
> > it and stopped building my own Xorg debs with the patch, living with the
> > absent monitoring overlays on those windows.
> >
> > Fast-forward to today; I'm using systemd-nspawn for running X clients -
> > particularly network-facing clients like FireFox where I _strongly_
> > prefer isolating the client from accessing things like my home directory
> > for obvious reasons (ssh keys, etc).
> >
> > These programs are cooperative and set _NET_WM_PID, but the PID they set
> > is from the perspective of the container namespace. The display server
> > is running in the global host namespace, where this PID has zero
> > relevance. The same goes for my window manager, it to runs in the
> > host's namespace, so when it gets this PID and tries to monitor the
> > process subtree rooted at that PID in /proc, it either finds nothing or
> > the entirely wrong tree.
> >
> > So again I'm wishing the display server would just set this property for
> > local clients immediately when creating the window, which would not only
> > make the property more reliable but now it would also set it from the
> > PIDNS of the Xorg server, that I would argue is far more meaningful.
> >
> > I happened to still have the old patch I was using to do this back in
> > the day, and have attached it as-is for discussion purposes.
> >
> > Thanks,
> > Vito Caputo
>
> it'd be much more reliable to set _NET_STARTUP_ID to the content of whatever
> the DESKTOP_STARTUP_ID env var has and enforce this in xlib itself. this can
> be
> inherited down the chain through your launching/containers/whatever and passed
> in for that launch instance. assuming your wm of course can do this and track
> every launch instance it started off and map it back to that instance... but
> it
> can know reliably then "THIS action of launching here resulted in that window
> over there". much better than _NET_WM_PID because the pid here may not be the
> pid of whatever was forked - but some other child process or even unrelated
> other pid.
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
These aren't mutually exclusive proposals and in my opinion are somewhat
complementary.
Consider that in my workflow I am often launching X clients manually
from bash via xterm. These won't have new startup IDs allocated to
them, so the monitoring overlays would reflect those of the top-level
WM-launched xterm. If the client PID matches somewhere deeper in the
heirarchy rooted by the startup ID, I'd default to narrowing the scope
to that level. It's /probably/ going to be the right thing, so I'd
still want the X client PID.
Speaking from years of experience using this scheme, keying off the PID
alone has been perfectly functional until namespaces came along. Maybe
it should be on a different property, like _UNIX_WM_PID or something,
just to not step on the existing sematics of _NET_WM_PID. But I think
it's perfectly reasonable to have the X server make this client
identifier as viewed by the X server more reliably accessible when
possible, considering it's the X server with the AF_UNIX socket and
associated creds at its disposal.
Thanks,
Vito Caputo
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
