distributions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "A. Wilcox" <AWilcox@Wilcox-Tech.com>
To: Thorsten Kukuk <kukuk@suse.com>, distributions@lists.linux.dev
Subject: Re: Y2038, glibc and utmp/utmpx on 64bit architectures
Date: Fri, 3 Mar 2023 10:51:54 -0600	[thread overview]
Message-ID: <7938DE1F-C31A-470F-A7CA-60DD8749C4B8@Wilcox-Tech.com> (raw)
In-Reply-To: <20230303104647.GA20891@suse.com>

On Mar 3, 2023, at 4:46 AM, Thorsten Kukuk <kukuk@suse.com> wrote:
> Hi,
> 
> I hope everybody is aware of the Y2038 problem. And not only for 32bit
> architectures, but also 64bit architectures are not ready today, at
> least not if they use glibc.
> glibc uses for compatibility with 32bit userland applications 32bit
> values for time_t and other variables even on 64bit systems.
> Affected is everything around utmp/utmpx, wtmp/wtmpx and lastlog.
> 
> I wrote a blog about how to solve that for utmp/utmpx by using the data
> from systemd-logind instead:
> https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit/
> 
> A detailed analysis also for wtmp and lastlog, which have the same
> problems, can be found here:
> https://github.com/thkukuk/utmpx/blob/main/Y2038.md
> 
> 
>   Thorsten
> 
> -- 
> Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
> SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany
> Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
> (HRB 36809, AG Nürnberg)

Hi Thorsten,

Please don’t require systemd for utmpx features.  It is not exactly
accurate that musl does not support utmp.  The musl view is that utmp
*in the libc* is insecure, but can be implemented securely using an
external process.  That process is the utmps package that you found.  It
does not require s6, other than skalibs (which is not a very heavy
dependency at all).

What if I also told you that systemd itself is a replacement for
`s6-ipcserver`? :)  All you need is a socket unit with Accept=Yes.  I
could wire up an example Fedora container that you could play around
with, using utmps and a custom built coreutils/util-linux against it,
over the weekend if it would help sway anyone’s mind.

I really don’t think it is appropriate to outright remove POSIX standard
interfaces from Linux, replacing them with non-standard systemd APIs.
The number of packages that use utmpx are numerous and far beyond what
you probably realise:

* tcsh uses it for its custom lastlog primitive.

* AccountsService uses wtmp.

* lynx uses it.

* net-snap uses it for exposing utmp information over MIBs.

* Xterm, urxvt, etc use it to update information on logged in shells.

* Python psutil package uses it to display status information.

* SDDM display manager updates wtmp/utmp for logged in sessions.

* lsof tool.

* libutempter, which is used by tmux and Konsole to update utmp.

* X11VNC, OpenSSH, procps, sysklogd, sudo…

These are just the packages we have in Adélie, and we are a small
distribution, which is also built on musl libc and has full utmpx
support.

It is much better to provide a secure way for the standard POSIX utmpx
header, than try to replace it and add all those conditionals to all
those packages.  Remember that in addition to distros that don’t have
systemd, there are other systems (BSD, Illumos, even Mac OS for some of
those) that will never have logind APIs, so you are asking all those
packages to special-case glibc Linux…

Best,
-A.

--
A. Wilcox (they/them)
SW Engineering: C/C++, DevOps, POSIX
Wilcox Technologies Inc.


  reply	other threads:[~2023-03-03 16:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 10:46 Y2038, glibc and utmp/utmpx on 64bit architectures Thorsten Kukuk
2023-03-03 16:51 ` A. Wilcox [this message]
     [not found] ` <3067bd0ec5134b039cdb8be9db8da8e5@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 17:07   ` Thorsten Kukuk
2023-03-03 20:09     ` Anna
2023-03-03 20:25     ` Bruno Haible
     [not found]     ` <c420abff6abd43cabac8c2fa5d812091@DB6PR04MB3255.eurprd04.prod.outlook.com>
2023-03-03 20:55       ` Thorsten Kukuk
2023-03-03 22:11         ` Bruno Haible

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7938DE1F-C31A-470F-A7CA-60DD8749C4B8@Wilcox-Tech.com \
    --to=awilcox@wilcox-tech.com \
    --cc=distributions@lists.linux.dev \
    --cc=kukuk@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).