Conversation

Notices

1. Embed this notice
   anna (navi@social.vlhl.dev)'s status on Thursday, 12-Jun-2025 08:31:49 JST anna

   • Rich Felker
   • Adrian Vovk
   @sertonix @dalias @AdrianVovk
   
   unless i'm mistaken, what i understood of that issue is that multiple 'gdm' users are needed, to render multiple login screens at once- not really multi-seat for the same logged-in user, which makes even less sense in my view
   
   so, am i wrong, or is gdm really not able to render multiple login screens under the same unix user? and if so what stops it from simply using multiple wayland and dbus sockets?
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 08:31:47 JST Rich Felker

     in reply to

     • Adrian Vovk

     @navi @AdrianVovk @sertonix I have no idea, but this is fundamentally a bug in gdm, not any underlying inherent limitation, that could be fixed right rather than with horrible hacks involving fake ephemeral users or namespaces, and that would then work on *all* systems (also BSDs etc.) not just GNU/Linux/systemd.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 08:34:46 JST Rich Felker

     in reply to

     • Adrian Vovk

     @navi @AdrianVovk @sertonix This is the frustrating thing I keep getting from the systemd sphere of Linux folks:

     "We need to build this Rube Goldberg machine of hacks to work around something else we refuse to fix, and everyone's systems need to be amenable to said Rube Goldberg machine. No we can't just fix the thing we refuse to fix instead."

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Adrian Vovk (adrianvovk@fosstodon.org)'s status on Thursday, 12-Jun-2025 10:05:56 JST Adrian Vovk

     in reply to

     • Rich Felker

     @navi @dalias @sertonix I mean it used to do that. That's literally what this announcement is about: instead of rendering multiple login screens under one user, we use discrete ephemeral users.

     I'll give the simplest reason to do this (there are others): remote login is the same as multiseat, and you _really_ don't want multiple different remote login screens running as one user. Otherwise pwning one pwns the rest. On X11 this is extra catastrophic because then you can keylog the other (1/2)

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 10:05:56 JST Rich Felker

     in reply to

     • Adrian Vovk

     @AdrianVovk @navi @sertonix Normal people do not have remote login screens whatsoever. This is entirely an 0.01% niche problem domain.

     It's expected that if your user account is pwned, it's pwned. I don't understand the concept of trying to make multiple remote login screens for the same user account into different privilege domains. If you run them as separate uids, you break the ability to do things the user wants to do, like attach their screen/tmux session from one on the other, but you don't break the power of the attacker to pwn one from the other. All they have to do is drop something malicious in .profile or similar, trojan a binary in ~/bin, or whatever.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 10:20:38 JST Rich Felker

     in reply to

     • Adrian Vovk

     @AdrianVovk @navi @sertonix Indeed it looks like I misunderstood what you were saying before (see subsequent reply in another branch of the thread).

     Completely understand if you don't want to rehash it, but I would be interested in what you think the mainstream application for remote GUI login screen is, vs starting a remote GUI session following a remote authentication process that didn't involve a GUI login screen provided by the remote system.

     I don't see how you can make the former secure.

   • Embed this notice
     Adrian Vovk (adrianvovk@fosstodon.org)'s status on Thursday, 12-Jun-2025 10:20:39 JST Adrian Vovk

     in reply to

     • Rich Felker

     @dalias @navi @sertonix They don't share a home directory... they're different users.

     As for the rest... sure. If you believe that so few scenarios require remote login then I can understand why you think this is an overcomplicated solution to a nonexistent problem. That belief is incorrect, but I really do not wish to argue about it so I'll leave it there.