i noticed this a while back but was never able to figure out what was going on ... it seems that the login from shadow tries too hard ... it tries to do the job of agetty which it probably shouldnt ... for example: This is vapier.(none) (Linux x86_64 2.6.11.12-grsec) 01:05:20 vapier login: alksfjalksdfj Password: Login incorrect This is \n.\O (\s \m \r) \t vapier login: that's odd ... why didnt my /etc/issue get parsed ? it's because that 2nd login prompt is not from agetty (which does parse /etc/issue) but rather from /bin/login ! to reproduce, emerge shadow with USE=-pam and run: agetty 38400 `tty` linux then type in an invalid username/password combo my understanding of the situation may be wrong, but i think the behavior is supposed to be: - agetty loads up, plays with the terminal, parses /etc/issue (translating all the escape sequences), outputs the 'login:', waits for and reads in the specified username, then executes the specified login program (/bin/login by default) - the login program receives the username, reads in the password, and then does the verification ... if verification fails, login exits - init restarts agetty on the terminal and everything starts over
I am going to assume you guys have to comment ISSUE_FILE in /etc/login.defs for non PAM builds ?
that would work around the problem i guess ... semi-related note ... if we've stopped using the official 'pam-login' package, why not fold pam-login's functionality back into the shadow ebuild ? we could punt the virtual/login cruft if we do ...
(In reply to comment #2) > that would work around the problem i guess ... > Not really a workaround ... if the getty do not support it, you can do it via ISSUE_FILE for non-pam login, or pam_issue for pam login. Guess shadow's login was just broken in that regards in the past. > semi-related note ... if we've stopped using the official 'pam-login' > package, why not fold pam-login's functionality back into the shadow ebuild ? > we could punt the virtual/login cruft if we do ... Yeah, that is the plan .. question is how, as pam-login is in the profiles. Maybe make a stub that just depend on specific shadow that does that until that shadow stable on all arches.
(In reply to comment #3) > (In reply to comment #2) > > that would work around the problem i guess ... > > Not really a workaround ... if the getty do not support it, you can do it via > ISSUE_FILE for non-pam login, or pam_issue for pam login. Guess shadow's > login was just broken in that regards in the past. no, i'm pretty sure it's always been like this ... the ability to have a pamless system is new though so it's just come up > > semi-related note ... if we've stopped using the official 'pam-login' > > package, why not fold pam-login's functionality back into the shadow ebuild ? > > we could punt the virtual/login cruft if we do ... > > Yeah, that is the plan .. question is how, as pam-login is in the profiles. > Maybe make a stub that just depend on specific shadow that does that until that > shadow stable on all arches. i think we have virtual/login in the profiles ...
*** Bug 110210 has been marked as a duplicate of this bug. ***
You still gonna fix /etc/login.defs for non-pam builds to not define ISSUE_FILE ?
4.0.13 already has this change ... it's still -* though cause i wanted you to review the updates first :)
newer versions have this "fixed"
*** Bug 122731 has been marked as a duplicate of this bug. ***
