Share the TTY device with systemd-logind

[thkukuk]

When sshd creates a session via PAM, it does not know the TTY and sets a dummy one. As result, systemd-logind has to parse utmp and find the correct entry to get the TTY afterwards. Instead tell systemd-logind the TTY device after we know it.

utmp on 64bit bi-arch systems like x86-64 are, with glibc, not Y2038 ready and glibc maintainers want to drop it because of this and for many other reasons (https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/). So going via utmp for the TTY will not work anymore in the near future.

[djmdjm]

Sorry, we are not willing to accept a dependency on libsystemd. If there is a way to communicate this information without taking the dependency (similar to what we're doing to avoid sd_notify()) then we'd consider it.

[bluca]

This is a D-Bus API, so you don't need libsystemd, but you need a D-Bus client implementation to call the relevant method. It's not something that can be implemented in a few lines of code like the readiness protocol. From a C program, that pretty much means either libglib or libsystemd.

Would it be acceptable if it was dlopened instead of linked, and only if a disabled-by-default runtime config in sshd_config is set?

[djmdjm]

We probably wouldn't be interested in dlopen()ing anything into sshd's address space, because it carries identical risks to direct linking. Maybe in a fork+exec'd subprocess, but that's obviously significantly more hassle.

[bluca]

Yes it pulls stuff in, however it is not identical: linking means it happens unconditionally on startup, while dlopen means it only happens on demand. If it is gated by a config option, it would only happen if the config is enabled, and it could also check whether systemd is running before doing it as well (trivial check if /run/systemd/system exists)