Hacker News Reader

Comment by tremon | Hacker News Reader

I don't believe the X system had/has a separate protocol for screen locking, or if it does, that any of the programs implement it. So xscreensaver is just another X client that happens to draw itself full-screen on top of all other apps and grab all user input.

From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.

View on HN

You don't need special X support for having a lightweight process monitor.

I'm imagining 2 processes:

1. Process monitor shows a fullscreen black window. Launches xscreensaver --lock or something as a child process

2. Xscreensaver shows the lock screen over the top of the process monitor, with a password prompt

When the correct password is entered, xscreensaver signals to its parent process. Then both processes close gracefully.

If xscreensaver crashes without signalling, the process manager silently restarts xscreensaver.

None of that requires any changes to X. You'd just want to be sure xscreensaver is displayed on top of the process manager's black window.

jwz wrote a document explaining why this is hard. (Note that this link may result in an unsavoury redirect if you click on it from here. You can, e.g. copy and paste it to avoid this.)

https://www.jwz.org/xscreensaver/toolkits.html

From the point of view of the display manager

Argh. That would be the window manager, of course.

xscreensaver + light-locker should be okay, there is no virtual keyboard.

There is also xsecurelock [1] by Google.

[1] https://github.com/google/xsecurelock

Reply on news.ycombinator.com