Announcement

Collapse
No announcement yet.

Fedora COSMIC Desktop Spin Being Considered

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • anda_skoa
    replied
    Originally posted by mSparks View Post
    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by anda_skoa View Post
    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.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by mSparks View Post
    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by anda_skoa View Post
    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.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by ssokolow View Post
    *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.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by mSparks View Post
    what do you mean by "it".
    The screen locker

    Originally posted by mSparks View Post
    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.


    Leave a comment:


  • ssokolow
    replied
    Originally posted by anda_skoa View Post
    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.)​

    Leave a comment:


  • mSparks
    replied
    Originally posted by anda_skoa View Post
    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.
    Last edited by mSparks; 20 February 2024, 09:08 PM.

    Leave a comment:


  • anda_skoa
    replied
    Originally posted by mSparks View Post
    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.

    Originally posted by mSparks View Post
    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.

    Originally posted by mSparks View Post
    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by anda_skoa View Post
    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.

    Leave a comment:

Working...
X