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. Martin-Éric
