Fedora COSMIC Desktop Spin Being Considered

[anda_skoa]

I am not aware of any X11 server that does not control both input and output, what was your point?

The point is that they don't implement screen locking but delegate it to another process which then has to deal with not having that level of immediate control.

It is not a consequence of either technology but a difference in architectural choice that makes a use case more or less complex.

Asynchronous means that things are not happening synchronously

Obviously.

And as said before there are many techniques to do that.
So even if some forms of authentication require asynchronous handling it does not imply doing that in a separate process.

And, again, even if the choice of asynchronous technique is a separate process, it can just deal with the authentication and still keep the hard bits of locking in the process that controls input and output.

X11 file servers and wayland system calls to create streams of bytes do exactly the same thing, with exactly the same libraries

See above.
An X11 server could of course implement locking directly and would thus only have to deal with the reduced complexity compare to the usual choice of delegating it to a separate application.

Equivalently, if you choose to delegate that on Wayland, you also have additional complexity.

A desktop project like COSMIC has all four options available:
* using an X11 server with built-in screen locking, e.g. a fork of Xorg with that additional feature
* using an X11 server which delegates screen locking, e.g. Xorg and xscreensaver
* using a Wayland compositor with built-in screen locking
* using a Wayland compositor which delegates screen locking

Given COSMIC's choice of Wayland that leaves them with two of those, I assumed they went with the simpler one.

[mSparks]

.
An X11 server could of course implement locking directly and would thus only have to deal with the reduced complexity compare to the usual choice of delegating it to a separate application.

google (and many others) seem to have settled on xsecurelock for their employees infrastructure

https://github.com/google/xsecurelock

if a project like cosmic is going to get wider acceptance its probably going to need to support the authentication modules written for that.

And, again, even if the choice of asynchronous technique is a separate process, it can just deal with the authentication and still keep the hard bits of locking in the process that controls input and output.

"the hard bits of locking" is that no single process (even a wayland compositor) owns input or output, in fact in most situations no single machine controls input or output. I've not seen any wayland compositor even start, let alone come close to solving those problems.

[royce]

This is why I keep saying that the System76 folks should make COSMIC closed source and only available to their customers, at least for a short time.

Oh yes, I'm sure this would go down well with their customer base, a lot of them OSS enthusiasts 🙄🤌🤌

[anda_skoa]

google (and many others) seem to have settled on xsecurelock for their employees infrastructure

https://github.com/google/xsecurelock

Good resource: the intro of its README has good examples of the difficulty of external lockers that simply can't happen with one that is part of the display server.

Which would of course be possible on X11 but is just not very common (if available at all).
It is more likely to be the case with Wayland as display server and compositor are usually one and often not a third party component.

Hence the assumption that screen locking would be less of a problem for COSMIC than what was suggested in the post I replied to.

if a project like cosmic is going to get wider acceptance its probably going to need to support the authentication modules written for that.

As you can see in its dependency list it is using libpam
Which is not surprising given that this is Linux's main authentication system with tons of plugins for various auth technologies.

Great system as it applies to graphical logins, local consoles, SSH, etc.
Pretty easy for example to add Google Authenticator based two-factor check

"the hard bits of locking" is that no single process (even a wayland compositor) owns input or output

They whole point of a Wayland compositor is to own both input and output.

[mSparks]

that simply can't happen with one that is part of the display server.

you are imagining a difference between code in a module and code not in a module that simply doesn't exist. it makes zero difference to the complexity of locking a desktop environment if the function to lock and unlock it is an external function or an internal one.

And if you want network authentication it has to be an external one.

[anda_skoa]

you are imagining a difference between code in a module and code not in a module that simply doesn't exist

But there is a difference between being in the same process or not.

Having it separately from the display server creates the well known difficulties.
One of the posters earlier thought that COSMIC might run into such difficulties because that is what other desktops were facing when they started.

Which is why I pointed out that COSMIC might have it easier if they have their own display server, which some Wayland based desktops do.
This is not a Wayland or X11 question. It is just very uncommon for a desktop to ship their own X11 server.

it makes zero difference to the complexity of locking a desktop environment if the function to lock and unlock it is an external function or an internal one.

It makes a massive difference if it is internal to the process which controls all input and output.
If it is in a different process then the known issues arise.

And if you want network authentication it has to be an external one.

Nonsense!

Nothing keeps a display server from performing network operations.
They already communicate over socket with their clients, in the X11 case possibly even via TCP/IP.

But even if in some parallel universe the server process would somehow be forbidden to do network I/O it could still just to the communication in an helper process and still perform all locking and unlocking functions itself.

[mSparks]

Having it separately from the display server creates the well known difficulties.

what do you mean by "it".

the complexity doesnt come from the display server, it comes from all the things connected to the display server; libinput, accessability tools, applications with root permissions and the graphics drivers.

windows does exactly what you are describing, last I checked (which admittedly was a year or two ago) this was still a thing:


If what you are suggesting was as easy as you are suggesting someone would have made a wayland screenlocker that is as versatile and secure as xsecurelock by now.

They haven't, because it's not.

[ssokolow]

As you can see in its dependency list it is using libpam
Which is not surprising given that this is Linux's main authentication system with tons of plugins for various auth technologies.

Great system as it applies to graphical logins, local consoles, SSH, etc.
Pretty easy for example to add Google Authenticator based two-factor check

*nod* It was easy for me to install libpam-u2f and set my system up to blink my Yubico USB/NFC U2F token whenever I try to login or sudo.

(Works great as a second factor if I choose to pull it when I leave, as a physical access requirement since I need to physically tap the button on something that can only be connected locally, and as a visual indication of unexpected attempts to elevate permissions if someone gets my password and tries to use it via SSH.)

[anda_skoa]

what do you mean by "it".

The screen locker

the complexity doesnt come from the display server, it comes from all the things connected to the display server; libinput, accessability tools, applications with root permissions and the graphics drivers.

That is complexity for the display server, not the screen locker.

The complexity for the latter depends on how it is implemented.
Doing it in the process that controls input and output avoids some of the challenges usually associated with screen locking.

For example one issue both xscreensaver and xsecurelock mention in their documentation is to ensure the lock screen content is always above any other client content.
If the display server would be doing it instead, it could simply not place any client's buffer data into its output.
It thus avoids client content being shown on top of lock screen content because there is no client content.

In one case the lock screen content is like a sheet of paper lying on top of the client content sheet of paper.
If either sheet moves, parts or all of the bottom sheet will become visible.

In the other case it is a "lock" sheet of paper lying on an empty desk because the "client" sheet has been removed.
No matter how much it moves, even if it is removed, there won't be anything from the other sheet visible because it is simply not there.

[anda_skoa]

*nod* It was easy for me to install libpam-u2f and set my system up to blink my Yubico USB/NFC U2F token whenever I try to login or sudo.

(Works great as a second factor if I choose to pull it when I leave, as a physical access requirement since I need to physically tap the button on something that can only be connected locally, and as a visual indication of unexpected attempts to elevate permissions if someone gets my password and tries to use it via SSH.)

Very nice setup!
Especially the visual indication of any authentication attempt.