Post B8XWX1bj2KFZfwtHua by cks@mastodon.social
 (DIR) More posts by cks@mastodon.social
 (DIR) Post #B8XVA2gqkGbMQ1lTsW by ariadne@social.treehouse.systems
       0 likes, 1 repeats
       
       @cks who(1) and friends use the utmp database, which requires root-level permission to update.systemd's logind is in part an attempt to deprecate utmp, alpine did the same with @ska's utmpd.
       
 (DIR) Post #B8XVkGAw5JbifS6hxQ by cks@mastodon.social
       0 likes, 0 repeats
       
       @ariadne @ska I should have mentioned: 26.04 has no /var/run/utmp, and the 26.04 'who' doesn't use it or a variant for the information (well, it tries, but it fails with ENOENT). Instead it seems to look around in systemd stuff and magically extract the information, even though logind/loginctl is all <shrug emoji> about it.
       
 (DIR) Post #B8XVvBoMeOPMJmlFuC by ariadne@social.treehouse.systems
       0 likes, 0 repeats
       
       @cks @ska that's weird, it is probably related to ubuntu's who(1) being the rust rewrite version.  it probably touches the logind stuff directly rather than using logind APIs.
       
 (DIR) Post #B8XWX1bj2KFZfwtHua by cks@mastodon.social
       0 likes, 0 repeats
       
       @ariadne @ska The Rust version does it too but we manually switched to GNU Coreutils (with some pain) for reasons. Coreutils appears to fall back to using systemd sd_* session stuff (so a library API) to create an emulated utmp if there is no real one.(Why the sd_* library stuff returns better information than logind/loginctl does is an interesting question. Part of it may be that the who code tries hard to guess based on eg /dev/pts timestamps if the API fails to have information.)
       
 (DIR) Post #B8XX7fFz6AqH4SC0SO by ariadne@social.treehouse.systems
       0 likes, 0 repeats
       
       @cks that's... bizzare.  i wonder if it is a regression?
       
 (DIR) Post #B8XYz3aZSm5hpyqSlk by aslakr@mastodon.social
       0 likes, 0 repeats
       
       @ariadne @cks  There is at least one bug report https://bugs.launchpad.net/ubuntu/+source/rust-coreutils/+bug/2152801 but I wonder if they will bother to fix it for this LTS
       
 (DIR) Post #B8XdzA2JzU2dbZh6GG by wolf480pl@mstdn.io
       0 likes, 0 repeats
       
       @cks AFAIK for that to work:- sshd's UsePAM needs to be enabled (make sure to disable KeyboardInteractiva and ChallengeResponse auth if UsePAM is enabled)- /etc/pam.d/sshd or whatever it includes must call pam_systemd.so in the session hook- dbus must be functionalbut there may be other reasons for it to not work
       
 (DIR) Post #B8XpSiCd8hF7SnoGAK by ska@social.treehouse.systems
       0 likes, 0 repeats
       
       @ariadne @cks I don't think alpine had any intention to deprecate utmp? It uses utmps because it's an implementation of utmp that does not need to make its clients suid or sgid, I don't think they're questioning the functionality itself.I do want to question the functionality, but that should be part of a larger endeavour studying the intersections with NSS and PAM, and hopefully redesigning the whole thing in a sane way. And utmp is clearly not the biggest elephant in the room.
       
 (DIR) Post #B8Y5XyKGDheOBOuPDM by cks@mastodon.social
       0 likes, 0 repeats
       
       @wolf480pl All of that appears to be in place, and certainly SSH logins get registered (with the correct session leader PID). They just don't have the TTY information (on a stock server install).