I still cant find an easy way to move processes around without /.config. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility. Fill the memory with some stuff Actual results: The session is killed Expected. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. This could probably be fixed with an X extension yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.Īnother issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).Īn option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. How would you signal X to lock/unlock what would it do if the lock client wasn't connected, etc.ī) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program it has to be the same program. In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.Ī) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch. It's just that the Xorg server can't detach. And there's no obstacle in printiple to implement this. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty. What you really want is detachable graphics session. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed. Wayland compositors also implement it through such a layer. The whole security then hinges on the locker not crashing. ![]() Using this option also implies verbose output. To save the log to a file, you can set the path using the -log option. ![]() You can also add verbose: True to the /.xscreensaver file to make it persistent. The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. To log verbose debugging information, start xscreensaver with the -verbose command line option. The very concept of locking the screen is flawed.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |