Conversation

Notices

1. Embed this notice
   Adrian Vovk (adrianvovk@fosstodon.org)'s status on Wednesday, 11-Jun-2025 19:30:38 JST Adrian Vovk

   I wrote a thing: "Introducing stronger dependencies on systemd"

   https://blogs.gnome.org/adrianvovk/2025/06/10/gnome-systemd-dependencies/

   • Rich Felker repeated this.
   • Embed this notice
     Natanael Copa (ncopa@fosstodon.org)'s status on Wednesday, 11-Jun-2025 19:30:35 JST Natanael Copa

     in reply to

     • Morten Linderud

     @Foxboron @AdrianVovk I would also like to point out that Adelie Linux devs have been doing impressive work trying to make musl work in upstream systemd.

     The difficulties are not the technical ones.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Natanael Copa (ncopa@fosstodon.org)'s status on Wednesday, 11-Jun-2025 19:30:37 JST Natanael Copa

     in reply to

     @AdrianVovk "So what should distros without systemd do?
     First, consider using GNOME with systemd."

     Alpine Linux can not do that because
     systemd explicitly does not support musl, and they have been pretty clear that they never will.

     So the only options we have are re-implementing systemd, or re-implementing glibc. Not only the public APIs but also the internals.

     Very frustrating.

   • Embed this notice
     Morten Linderud (foxboron@chaos.social)'s status on Wednesday, 11-Jun-2025 19:30:37 JST Morten Linderud

     in reply to

     • Natanael Copa

     @ncopa @AdrianVovk

     Fwiw, the systemd maintainers are open to supporting musl and there has been progress on these parts because of postmarketos.

     Rich Felker repeated this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 06:47:31 JST Rich Felker

     in reply to

     @AdrianVovk Why have a hard dependency for features basically nobody wants or needs? Multi-seat/multi-graphical-session on same host, much less with same user at each seat, it an utterly wonky special case only the most nerdy possible users would even think of. Just make it so folks can turn off support for whatever breaks without systemd dynamically creating fake ghost users as a hack to make that work.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 12-Jun-2025 06:49:04 JST Rich Felker

     in reply to

     @AdrianVovk GNOME logic: users shouldn't be allowed to control/customize new and unwanted behaviors in the file chooser dialog, but absolutely need to be able to do complex multi-seat stuff!

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr OK, that wasn't clear til now. So basically this is a privsep login screen that's running as an ephemeral user not associated with the actual user logging in, so that it doesn't need to be running as root? And you want them to be different users per login screen so that popping one wouldn't allow attacks on another?

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

     in reply to

     • Rich Felker
     • Todd Knarr

     @tknarr @dalias the sessions are not running under different UIDs. Once you log in you're logged in as yourself. Only the login screen runs as different UIDs

   • Embed this notice
     Todd Knarr (tknarr@mstdn.social)'s status on Thursday, 12-Jun-2025 10:09:06 JST Todd Knarr

     in reply to

     • Rich Felker

     @dalias @AdrianVovk I can think of a use: logging in using one session with a new desktop environment to check it's configuration without having to log out of my old desktop environment first. But in that case I absolutely want the new session to be the same UID as the older one because I want to be the same user as far as the system's concerned, not someone else.

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr If my understanding is correct, that's completely reasonable, but it should work with static assignment of these UIDs if that's what someone wants, and for the vast vast vast majority of users, there's only a single one (because again, normal people have a single seat, they're not running 1990s style uni thin-client labs or anything).

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

     in reply to

     • bluca

     @bluca @AdrianVovk It's kinda cute how you like arguing with this silly caricature of me that lives in your head... 🙃

   • Embed this notice
     bluca (bluca@fosstodon.org)'s status on Thursday, 12-Jun-2025 10:11:47 JST bluca

     in reply to

     • Rich Felker

     @dalias @AdrianVovk yeah! Who needs features like sensible remote desktop anyway? It's not in POSIX, so nobody should have it!!111 🤡

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr That overall sounds good. Does that mean it's expected to break at some point in the future? Or will you keep support for passwd/shadow for systems that don't want to or can't use the systemd-style accountservice?

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

     in reply to

     • Rich Felker
     • Todd Knarr

     @dalias @tknarr Indeed. That is the workaround I implemented for non-systemd distros, as explained in the blog post. And, again as I explained in the post, the workaround will remain until another unrelated component (accountsservice) is replaced with userdb for unrelated reasons (because it provides us with rich user records, unlike /etc/passwd)

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

     in reply to

     • Rich Felker
     • Todd Knarr

     @dalias @tknarr Yeah it's expected to break at some point in the future, because userdb will be required by accountsservice/its replacement

     userdb isn't incompatible with /etc/passwd or shadow in any way (in fact, to implement it right you're supposed to integrate it with shadow if you have it). It should be possible to implement on any Unix system, I don't think there's anything Linux specific about it (but I'm no expert in non-Linux Unixes)

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr Is there a reason the default fallback userdb implementation can't just pull the data from passwd/shadow like always?

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr And..?

     That is all progressive enhancement you can do if running on a system that has those things.

     If not, you treat all the additional optional fields as empty.

     There is no good reason for any of that to be a hard dependency.

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

     in reply to

     • Rich Felker
     • Todd Knarr

     @dalias @tknarr For one, /etc/passwd doesn't have any form of rich information about the user. No profile pictures, no ability to export any kind of user settings to the login screen, etc. It barely has the ability to store a display name (which is actually "GECOS" instead, which is... complicated for historical reasons). userdb is json, so we can add new stuff to it whenever we want instead of going in and implementing weird side databases (which is how shadow and accountsservice happened, btw)

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

     in reply to

     • Todd Knarr

     @AdrianVovk @tknarr OK, I guess if/when distro folks hit this I'll help them write a stub that just translates passwd/shadow... *sigh*

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

     in reply to

     • Rich Felker
     • Todd Knarr

     @dalias @tknarr For two, this fallback code is a second codepath that will never be tested and will work completely differently from the first one. Thus, it will be broken and unmaintainable. I'm not signing myself up to deal with that, sorry. Really, userdb isn't that hard to implement. You just need to know the specifics of your distro (which may be using a weird non-shadow auth system, or a different C library, or a different init system, or all of the above) that GNOME can't know

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

     in reply to

     • Todd Knarr

     @tknarr @AdrianVovk AIUI that's the premise and it's a very valid one. It's the same sort of premise as privsep in sshd preauth, that you want to ensure one compromised process used for interacting with the not yet authenticated user can't be used to attack the credentials of another.

   • Embed this notice
     Todd Knarr (tknarr@mstdn.social)'s status on Thursday, 12-Jun-2025 20:32:59 JST Todd Knarr

     in reply to

     • Rich Felker

     @dalias @AdrianVovk More importantly, gdm shouldn't be running anything untrusted so the only way an attacker would be able to spy on gdm windows is if they've compromised the gdm user account itself by some other route, in which case you've got bigger problems. The usual solution there is session-based authentication with the information not persisted to the gdm user's .Xauthority file.

   • Embed this notice
     Todd Knarr (tknarr@mstdn.social)'s status on Thursday, 12-Jun-2025 20:33:00 JST Todd Knarr

     in reply to

     • Rich Felker

     @dalias @AdrianVovk That shouldn't require different UIDs, though. X11 has authentication that operates per-session, not per-user, so that applications opened on one display can't access windows from a session on another display even if both sessions belong to the same user. I ran into this a lot and had to create login scripts that played games with xauth to allow cross-session access.

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

     in reply to

     • Todd Knarr

     @tknarr @AdrianVovk I would imagine they have in mind a systemd-managed homedir model where your homedir isn't mounted/unlocked unless you're logged in and ssh is impossible..

   • Embed this notice
     Todd Knarr (tknarr@mstdn.social)'s status on Thursday, 12-Jun-2025 20:36:46 JST Todd Knarr

     in reply to

     • Rich Felker

     @AdrianVovk @dalias Why would that be in a system database though? There's a long-standing convention of storing that under the user's account, usually in dot-files in the user's home directory, .plan and .project for example. .userphoto would be an easy addition. GECOS isn't that complex, it's just a comma-separated list of items and the display name is the first one so trivial to parse out.

   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Thursday, 12-Jun-2025 21:05:18 JST Haelwenn /элвэн/ :triskell:

     in reply to

     • Rich Felker
     • Todd Knarr

     @dalias @AdrianVovk @tknarr Given the issue seems to be a codepath one, couldn't it still use backend-agnostic APIs like getpwnam(3) and getspnam(3) for the login information and another one for the extra metadata just like it's done when authentication servers like LDAP are involved ?