Ühel kenal päeval, L, 29.07.2017 kell 12:58, kirjutas R0b0t1: > On Sat, Jul 29, 2017 at 11:17 AM, Mart Raudsepp <l...@gentoo.org> > wrote: > > Ühel kenal päeval, L, 29.07.2017 kell 13:20, kirjutas tuxic@posteo. > > de: > > > The task is already accomplished :) with a mixture of WM-based > > > hotkey definitions and a delayed commandline utility (main,scrot, > > > imagemagick). > > > Addtionally I dont think that my X11 uses framebuffer (not shure > > > about that, though)... > > > > Those tools work by using an inherent X11 security hole by reading > > out > > the root window, it's not relevant to framebuffer in the kernel > > sense. > > > > Note that you can't use a global shortcut key in X11 while a > > typical > > right click context menu is open, because these take a X11 grab and > > even screen lock can't activate.. Then only the delay approach will > > work (if desired then together with a shortcut if the shortcut key > > is > > hit before opening the context menu). Fortunately in this case you > > only > > wanted a dropdown in firefox, which isn't implemented like that. > > This popup menu problem is solved with Wayland (most importantly > > the > > not screenlocking aspect of it), but so is the root window security > > hole, so the compositor/WM needs to take the screenshot and tools > > like > > import/scrot won't work. > > > > I'm not really sure it is fair to call that a security problem. It's > intentional, and that is because there are plenty of things that need > access to the whole desktop at once. E.g. automating anything that > doesn't expose a development API or have an accessibility API can > pretty much only be done by scraping the contents of the screen - > these programs simply don't work in Wayland? That seems like a > misfeature.
I'm calling things as they are. It is intentional only to the point of it not having been a concern back in the 1980s during X11 protocol designing. Any program running under the user can see the whole contents of their screen - not just their own; that's how these screenshotters work too, but it's easy to think of more nefarious use cases. Any program running under the user can listen to all key events meant for any other X application - that's how global shortcuts from random daemons or whatnot work (instead of DE provided hooks). It is trivial to write a key snooper. Now yes, this is local issues, so hopefully you are good on remote access issues, but if not, it might be game over for your terminal entered ssh passwords or whatever. There exist some mitigation techniques in the form of some non-standard X modules and other means, but they are usually not used and also can break such non-nefarious tools that make use of these aspects. Due to it being local (unless you for some reason enable TCP for X.org or something...) you can probably not worry about it too much, but it doesn't change the fact that they are security issues to the core of X.org, carried over from the 1980s. To solve these things in Wayland, there are cross-desktop protocols being specified to achieve these in a more arbitrated, correct and secure manner. There is proper isolation between applications.
