Announcement

Collapse
No announcement yet.

Fedora COSMIC Desktop Spin Being Considered

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

  • mSparks
    replied
    Originally posted by ssokolow View Post

    System libraries aren't processes. I'm talking about which running process has the decision-making authority.
    libinput and mesa run their own processes, you access them with system libraries.
    The fact you and anda_skoa​ don't know this just highlights neither of you a clue what you are talking about.

    Heck, libinput is a whole stack of processes.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by mSparks View Post

    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.
    System libraries aren't processes. I'm talking about which running process has the decision-making authority.

    Leave a comment:


  • mSparks
    replied
    Originally posted by ssokolow View Post

    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.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by mSparks View Post

    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.

    Leave a comment:


  • mSparks
    replied
    Originally posted by ssokolow View Post

    ...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.
    Last edited by mSparks; 23 February 2024, 04:50 PM.

    Leave a comment:


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

    Leave a comment:


  • mSparks
    replied
    Originally posted by anda_skoa View Post
    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).
    Last edited by mSparks; 23 February 2024, 12:59 PM.

    Leave a comment:


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

    Leave a comment:


  • ssokolow
    replied
    Originally posted by mSparks View Post

    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.
    Last edited by ssokolow; 23 February 2024, 08:35 AM.

    Leave a comment:


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

    Leave a comment:

Working...
X