Control: severity -1 normal Control: tags -1 = wontfix Control: retitle -1 login: util-linux variant uses vhangup
* Martin-Éric Racine <[email protected]> [240806 09:46]: > ti 6. elok. 2024 klo 10.19 Martin-Éric Racine > ([email protected]) kirjoitti: > > > > ti 6. elok. 2024 klo 10.13 Chris Hofstaedtler ([email protected]) kirjoitti: > > > > > > Control: tags -1 + unreproducible moreinfo > > > > > > On Tue, Aug 06, 2024 at 09:35:52AM +0300, Martin-Éric Racine wrote: > > > > The latest upload to unstable breaks login. Running the 'login' command > > > > consistently returns SIGHUP. This effectively prevents logging in. > > > > > > Works for me. Please provide additional info on when/how this > > > happens. > > > > When is systematically. > > > > I'm really not sure of what info would match 'how'. > What I run: 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. > sudo --preserve-env chroot /srv/chroot/unstable-i386/ login "$USER" > > Since this morning's 'login' update, this returns SIGHUP. 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
