to 8. elok. 2024 klo 9.35 Martin-Éric Racine ([email protected]) kirjoitti: > > ti 6. elok. 2024 klo 11.28 Martin-Éric Racine > ([email protected]) kirjoitti: > > > > ti 6. elok. 2024 klo 11.15 Chris Hofstaedtler ([email protected]) kirjoitti: > > > > > > 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. > > > > None of these is a drop-in substitute. I still need something similar > > to the above recipe to succesfully log me into a chroot. > > 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.
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
