sd-login: sd_session_get_tty() fails with pseudo terminals (pts)

[thkukuk]

systemd version the issue has been seen with

252, 250

Used distribution

openSUSE Tumbleweed, Fedora 36

Linux kernel version used

6.1.12-1-default

CPU architectures issue was seen on

x86_64

Component

systemd-logind

Expected behaviour you didn't see

sd_session_get_tty (sessionid, &tty) should return the TTY for a session like loginctl show-session <sessionid> does for the same session id.

Unexpected behaviour you saw

If you login on console, sd_session_get_tty (sessionid, &tty) returns the TTY (tty1 in this case).
If you login to the system via ssh (so TTY is pts/0), sd_session_get_tty (sessionid, &tty) returns an error, since /run/systemd/sessions/ does not contain the TTY entry.

But loginctl show-sesssion <sessionid> contains TTY=pts/0 in the output.

loginctl and sd_session_get_tty (sessionid, &tty) should always return the same device.

Steps to reproduce the problem

See above, once login on a console (tty = /dev/tty1), run loginctl show-session and write a short tool which calls sd_session_get_tty (sessionid, &tty). Both will return tty1.

Now login via ssh (tty = /dev/pts/0), run loginctl show-session and call the tool for this session again, loginctl will show the TTY=pts/0, but sd_session_get_tty (sessionid, &tty) will fail.

Additional program output to the terminal or log subsystem illustrating the issue

sd_session_get_tty(22) failed: No data available

But:
loginctl show-session 22 |grep TTY
TTY=pts/0

[poettering]

this is a limitation of ssh, and has nothing to do with pty or not.

SSH invokes the PAM session hooks before allocating a pty for a connection. That's because it simply doesn't know if it will need a pty at all, it could also be a connection for sftp or some other ssh sub-protocol. Or it could be a multiplexed connection that established multiple pty allocations.

See 3d0ef5c

So we currently use utmp as source of information for working around this mess, but I understand you want to get rid of precisely that. No idea what I can recommend then: ssh doesn't tell us anything about ptys it allocates if you have no utmp.

[poettering]

SSH invokes the PAM session hooks before allocating a pty for a connection.

this is different for getty or eve traditional rlogin/rsh logins, whre the pty was allocated before the login.

[thkukuk]

Thanks for the background, didn't had the time yet to look myself at the code.
Is there an interface which such applications could call to tell systemd the "missing information"?
We need a login() replacement anyways, so that we could let the new login() update the information for logind instead writing them to /run/utmp?

[poettering]

I guess we could add a dbus api for that, i.e. like what we did in 4885d74, just for the tty field.

but not sure how you'd convince ssh people to call that. and i am not aware of any other api we can abstract logind behind that they'd be willing to call.

iirc ssh doesn't invoke /bin/login on login.

[thkukuk]

I mean the login() function, not the login application. The function is called by sshd to update the utmp and wtmp entries, and the function adds the TTY. Should be simple to overwrite that function and update the logind data.

[poettering]

"simple to overwrite"? how so? LD_PRELOAD? yuck...

what might be nice if glibc would understand a logic where if /run/utmp is found to be an AF_UNIX stream socket inode it would just connect() to it, and then write the utmp record into that instead of the file. We could then make logind listen on that, and would receive the data directly onto our doorstep. Of course the timestamp would still be 32bit only, but we could just ignore that field.

btw, utmp has 20 bytes of "unused" space at the end, have you ever thought about just adding a 64bit time field there?

[thkukuk]

"simple to overwrite"? how so? LD_PRELOAD? yuck...

No, but if we replace wtmp we need a new library providing the necessary functions. And this could contain a different login() function. And latest if glibc developers really deprecate everything belonging to utmp/wtmp and don't allow to link against it anymore, this packages needs to be adjusted.

btw, utmp has 20 bytes of "unused" space at the end, have you ever thought about just adding a 64bit time field there?

Yes, but:

1. glibc developers made pretty clear that they will not accept any patches to fix the issue but plan to deprecate and remove the functionality
2. does not solve the other problems/bugs around utmp implementation, like the currently possible DoS attacks
3. would require to modify majority of packages to correctly read and write the new entry and understand new and old format, not everybody is using the "official" functions and macros for this.

So yes, alternate solutions were discussed, there are even patches for this, but in the end they got all rejected as not really solving the problems, far too much work and incompatibilities.

[poettering]

hmm, a new library?

you could just make it libpam, no?

i mean, not a big fan of the complexity of PAM, but it would mean a relatively minor update. i.e. a new hook as part of the "session" stack of PAM. if modules implement that they get called.

this would be wrapped by a new PAM function that would behave similar to login(), but pass the data off to the pam stacks.

[thkukuk]

The plan was that wtmp support will become a PAM module, but I haven't done a POC yet and looked at all the code if we can cover all functionality. One step after the other.
The "tty" problem seems to be unique to sshd. sshd seems to be also the only package which uses the login() function call, haven't found that anywhere else. So I'm pretty sure we will find a solution, we just need a way to tell logind the TTY later so that we don't need to go the way via utmp.

[poettering]

login() is just a BSD helper around pututxline() iirc, right?

systemd uses pututxline() directly when it writes to utmp (which it does if you use UtmpIdentifier=, UtmpMode=)

So maybe searching for login() invocations might not find anything, but pututxline()/pututline() might?

[thkukuk]

There are three different ways applications create utmp entries:

1. using login()
2. using pututline() or pututxline() (with glibc both are the same)
3. writing to utmp directly

openssh is the only one I found which uses login(), nearly everything else is using pututline(), the few remaining one can be ignored, old stuff not from interest as they don't write entries from type "LOGIN_PROCESS" and I couldn't find anything reading/using such entries.

For applications which allow "logins" (so login, xdm, gdm, sddm, ...) openssh is the only one which does not know the tty at the time it calls the PAM functions. There are a few more display managers, which mess this up by providing fake names to PAM and utmp, but this is fixable upstream.
For cases like openssh I have a working PoC which can read the tty from login()/pututline()/pututxline(). I just need to pass an additional CFLAGS entry and link against an extra library. All I need now is an interface, which allows me to tell login the correct tty.

[thkukuk]

This should be fixed with the PR.