#1078023 login: util-linux variant uses vhangup

Package:
login
Source:
login
Description:
system login tools
Submitter:
Martin-Éric Racine
Date:
2026-01-10 10:59:55 UTC
Severity:
normal
Tags:
#1078023#5
Date:
2024-08-06 06:35:52 UTC
From:
To:
The latest upload to unstable breaks login. Running the 'login' command consistently returns SIGHUP. This effectively prevents logging in.

I've thus had to do backflips with 'chroot' and 'su' just to be able to file this bug report.

Martin-Éric
#1078023#10
Date:
2024-08-06 07:09:21 UTC
From:
To:
Control: tags -1 + unreproducible moreinfo

Works for me. Please provide additional info on when/how this
happens.

Chris
#1078023#17
Date:
2024-08-06 07:19:47 UTC
From:
To:
ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler (zeha@debian.org) kirjoitti:

When is systematically.

I'm really not sure of what info would match 'how'.

Martin-Éric
#1078023#22
Date:
2024-08-06 07:46:02 UTC
From:
To:
ti 6. elok. 2024 klo 10.19 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:

What I run:

sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER"

Since this morning's 'login' update, this returns SIGHUP.

Meanwhile:

sudo --preserve-env chroot /srv/chroot/stable-amd64/ login "$USER"

This presents me with the password prompt as normal.

Martin-Éric
#1078023#27
Date:
2024-08-06 08:10:20 UTC
From:
To:
ti 6. elok. 2024 klo 10.46 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:
functionality. I can login using the above receipe as before.

Martin-Éric
#1078023#32
Date:
2024-08-06 08:15:27 UTC
From:
To:
* Martin-Éric Racine <martin-eric.racine@iki.fi> [240806 09:46]:

See, that's exactly the relevant info that was missing in your bug report. I
was assuming agetty was running login for you. When you do something manually,
or change something that's not the default, please put it into the report.

Right. This is documented in login(1):

| A recursive login, as used to be possible in the good old days, no longer
| works; for most purposes su(1) is a satisfactory substitute. Indeed, for
| security reasons, login does a vhangup(2) system call to remove any possible
| listening processes on the tty. This is to avoid password sniffing. If one
| uses the command login, then the surrounding shell gets killed by
| vhangup(2) because it’s no longer the true owner of the tty. This can be
| avoided by using exec login in a top-level shell or xterm.

As the man page says, give su a try, or runuser, depending on your usecase.
Or a container manager might be an even better solution, again, depending on
your usecase.

Anyway, this is intended behaviour, so I'm not going to change that.

Chris
#1078023#43
Date:
2024-08-06 08:28:23 UTC
From:
To:
ti 6. elok. 2024 klo 11.15 Chris Hofstaedtler (zeha@debian.org) kirjoitti:

None of these is a drop-in substitute. I still need something similar
to the above recipe to succesfully log me into a chroot.

Martin-Éric
#1078023#48
Date:
2024-08-08 06:35:29 UTC
From:
To:
ti 6. elok. 2024 klo 11.28 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:

This gets worse. My current recipe:

sudo --preserve-env chroot /srv/chroot/"$1" su --login "$USER"

One cannot run 'debsign' in this chroot anymore:

gpg: signing failed: Operation cancelled

Sorry, but "try something or something else" really won't do.

Martin-Éric
#1078023#53
Date:
2024-08-08 08:24:04 UTC
From:
To:
to 8. elok. 2024 klo 9.35 Martin-Éric Racine
(martin-eric.racine@iki.fi) kirjoitti:

In case anyone runs into the same issue, the equivalent using 'su'
(but without actually loging in) is:

sudo --preserve-env chroot /srv/chroot/"$1" su --pty - "$USER"

The important part is to create the pty, otherwise, e.g. gpg will fail.

Martin-Éric
#1078023#60
Date:
2025-03-29 19:35:13 UTC
From:
To:
Just saying that I am also seeing issues with the new login binary
related to SIGHUP.

In my case it's login being started by rsh-redone-server (85-4) (from
xinetd). What seems to be happening is that the vhangup triggers a
POLLHUP in in.rlogind, and the read on that file descriptor then
returns EIO, resulting in in.rlogind immediately closing the
connection.

It might be worth pointing out that telnetd still seems to work -
looking at the telnetd source code, there appears to be some special
handling for that case (see pty_read in utility.c):

 * In particular, EIO is known to appear when
 * reading off the master side, before having
 * an active slave side.

So maybe rlogind.c now also needs that kind of special handling? But
then again, doing a hangup on login actually seems a bit strange...


BTW, I have to admit that I am actually seeing this on Ubuntu 25.04
beta now, but I don't think it's an Ubuntu-specific issue.


Christof
#1078023#65
Date:
2025-03-30 13:51:51 UTC
From:
To:
* Christof Meerwald <cmeerw@cmeerw.org> [250329 20:45]:

Please file bugs against the packages that call login and where you
see problems.

vhangup is a security mechanism. We won't be turning it off.

Chris
#1078023#78
Date:
2026-01-10 10:10:41 UTC
From:
To:
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.
#1078023#83
Date:
2026-01-10 10:10:41 UTC
From:
To:
Es gibt eine Familienspende in Höhe von 1.850.000,00 USD von Cheng Charlie
Saephan. Bitte antworten Sie für weitere Informationen. Denken Sie daran,
Ihrer Familie und den Bedürftigen in Ihrer Umgebung Gutes zu tun.

Dies ist bereits der zweite Versuch, Sie zu erreichen. Bitte antworten Sie
für weitere Details.