Fedora COSMIC Desktop Spin Being Considered

[mSparks]

Who said anything about a GPU driver?

The display server is not the same as a GPU driver.
The GPU driver is part of the display server's output stack, but it is not involved in input handling, communication between clients and server, or screen locking.

you said it got benefits from being in the same process?
every GPU has its own process, and generally everything that accesses it has equal rights.

[anda_skoa]

you said it got benefits from being in the same process?

Correct.
Locking in the display server process.

How you arrived at the driver level is anyone's guess.

[mSparks]

Correct.
Locking in the display server process.

How you arrived at the driver level is anyone's guess.

so you arent talking about a screen locker, but a display server locker.

what use is that?

[ssokolow]

so you arent talking about a screen locker, but a display server locker.

what use is that?

By that metric, nobody except maybe Windows has a screen locker, because nobody but Windows puts the relevant code inside the kernel. The point of the Wayland approach is to stop having "screen locker" mean "Ordinary, unprivileged program cobbles together an approximation of screen locking by requesting various types of exclusivity from the display server".

Once the logic for locking/unlocking/enforcing/etc. is in the display server and the application-layer stuff is just things like the eye candy (how Windows .scr executables work), then you solve problems like "Having an open menu prevents the screen from locking because they use the same input device exclusivity API and there's no secure way to tell whether the screen-locker is really an attacker trying to break an existing screen-lock". (I imagine the reason they can't just add a new "privileged API only accessible to something launched with elevated privileges" for the real screen-locker to use is that XGrabKeyboard and friends are too stateful and having something trump them broke too many in-the-wild applications.)

Basically, if an X11 screenlocker dies, your screen unlocks because X11 doesn't actually have a concept of "screen locking"... just programs that are "badly behaved" to virtuous ends. If an in-display-server locker dies, then the things the attacker was trying to get access to die too unless there's a procedure in place for the compositor to losslessly restart... in which case, the same procedure can persist the lock.

As for "display server locker" as opposed to "screen locker", even X11 can solve that side of things. It's just a matter of making sure the kernel and the display server are on the same page about how the locker is supposed to ask for temporary exclusivity sufficient to disable things like Ctrl+Alt+F# hotkeys.

[anda_skoa]

so you arent talking about a screen locker, but a display server locker.

No, but I can see how such a long thread can get confusing.

We have been discussing screen locking and in particular how this task is less complex when implemented as part of the display server due to having direct control over input and output.

[mSparks]

No, but I can see how such a long thread can get confusing.

We have been discussing screen locking and in particular how this task is less complex when implemented as part of the display server due to having direct control over input and output.

but you are talking exclusively about locking the display server.
That doesn't actually lock the screens, a display server is just one of many userspace applications that need to be locked to lock the screens - they just generally offer the UI to do so.

pretty much every kernel links 4 or 5 tty outputs to the screen for example, terminal windows can spawn their own screens and display server connections (e.g. waypipe on wayland).

[ssokolow]

pretty much every kernel links 4 or 5 tty outputs to the screen for example, terminal windows can spawn their own screens and display server connections (e.g. waypipe on wayland).

...and the display server provides as good a place as any to coordinate with the kernel to gate access to those.

For the former, all it takes is making sure there's agreement between the kernel and display servers on how to block switching out the TTY outputs. XFree86 used to do that accidentally whenever it crapped out because its userland driver infrastructure required it to handle switching away from the X11 VT in a manner similar to how window dragging gets started when using CSDs. (i.e. It would take an exclusive grab on the input devices and handle Ctrl+Alt+F# itself so it could put the display into a known state first.)

I remember having to keep a laptop on hand so I could SSH in and kill XFree86 that way when it seized up.

For the latter, you're going to have to clarify, because that looks like a "not even wrong" problem from where I'm standing... If anything, I'd consider it a bug if I tried SSHing into my home PC and discovered that, to get access, I'd have to phone home and tell a family member my password to unlock the screen locally.

[mSparks]

...and the display server provides as good a place as any to coordinate with the kernel to gate access to those.

For the former, all it takes is making sure there's agreement between the kernel and display servers on how to block switching out the TTY outputs. XFree86 used to do that accidentally whenever it crapped out because its userland driver infrastructure required it to handle switching away from the X11 VT in a manner similar to how window dragging gets started when using CSDs. (i.e. It would take an exclusive grab on the input devices and handle Ctrl+Alt+F# itself so it could put the display into a known state first.)

I remember having to keep a laptop on hand so I could SSH in and kill XFree86 that way when it seized up.

For the latter, you're going to have to clarify, because that looks like a "not even wrong" problem from where I'm standing... If anything, I'd consider it a bug if I tried SSHing into my home PC and discovered that, to get access, I'd have to phone home and tell a family member my password to unlock the screen locally.

right, and that and all the other stuff is the hard part.
doesnt matter if its a wayland or an X11 display server, its still the hard part, because the problems are the same for both and they both use the same system libraries.
Locking the display server is and always was the easy part - actually easier for an X11 display server than wayland, because all the data pipes and the data they should contain are very clearly defined with an X11 server, wayland otoh, is just a random collection of system calls.

[ssokolow]

right, and that and all the other stuff is the hard part.
doesnt matter if its a wayland or an X11 display server, its still the hard part, because the problems are the same for both and they both use the same system libraries.
Locking the display server is and always was the easy part - actually easier for an X11 display server than wayland, because all the data pipes and the data they should contain are very clearly defined with an X11 server, wayland otoh, is just a random collection of system calls.

The point is that, with Wayland as implemented so far, the screen locker and the thing that gates access to the input devices are in the same process while, in X11, the screen locker is just another process and it's proven problematic to reconcile that with things that use the same APIs for stuff as simple as ensuring that clicking outside a popup menu will close it.

[mSparks]

The point is that, with Wayland as implemented so far, the screen locker and the thing that gates access to the input devices are in the same process while, in X11, the screen locker is just another process and it's proven problematic to reconcile that with things that use the same APIs for stuff as simple as ensuring that clicking outside a popup menu will close it.

No, the system libraries gate the access, libinput for input, the gpu driver (generally mesa aiui) for the screens, wayland accesses those system libraries in exactly the same way as X11, because they are defined by the system/kernel, not the display server.