4 ms·

I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-line

by c0l0 5y ago

I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-liner, which catches all the conscious X11 selection accesses (and a few unconscious ones, too :)) I provoked on my desktop during a few minutes of testing: sudo bpftrace -e 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S ");printf("%-6d\n", pid);}' I am not familiar with Xlib/X11 at all, so I am not sure which library functions one would be most interested in to explore this much further. Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in bpftrace invocation.

CyberShadow 5y ago
I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).
- c0l0 5y ago
  My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all. You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )
  - CyberShadow 5y ago
    I think XConvertSelection would be more effective. Applications which use the XFixes extension to receive notifications of new owners won't need to use XGetSelectionOwner.

by c0l0 5y ago

CyberShadow 5y ago

I am not familiar with bpftrace (though that does look extremely potent), but XSetSelectionOwner is called when an application wants to make data available via the clipboard, not access it. Also not sure if that would also catch stuff with Xlib, and I guess it won't if it's statically linked (this is why I pivoted hax11 from hooking library calls to MITM-ing the connection).

c0l0 5y ago
My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all. You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )
- CyberShadow 5y ago
  I think XConvertSelection would be more effective. Applications which use the XFixes extension to receive notifications of new owners won't need to use XGetSelectionOwner.