3 ms·
True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.
by justinjlynn 5y ago
True, and certainly a fair distinction. Perhaps I should say that a vulnerability of this nature - involving an xscreensaver fork - has occurred in practice.
- jraph 5y agoYes, your point still stands, this class of bugs is "fatally" present on X11, there is seemingly nothing that can be done about it.
- makomk 5y agoIt can actually be avoided on X11 if you're willing to make the screensaver an integral part of the desktop environment. The way KDE has done it since the KDE 4 era at least is by doing the actual screen locking in ksmserver and having the unlock screen and password entry dialog as a seperate process. This has two effects: crashing the password entry dialog or the screensaver will not unlock the desktop, and if you do somehow manage to crash ksmserver the session will immediately terminate, because ksmserver exiting for any reason is how X decides that the session is over. This is a bit like Wayland's solution, except with much less potentially buggy and crashy code in the process responsible for locking the desktop.