Fedora COSMIC Desktop Spin Being Considered

[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.

[mSparks]

The screen locker

So what is an example of this screen locker that is part of the GPU driver process you were thinking of?

Because I'm not aware of any GPU driver that offers such functionality.

[anda_skoa]

So what is an example of this screen locker that is part of the GPU driver process you were thinking of?

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.