bugzilla-daemon at mindrot.org
2003-Aug-24 01:51 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 dtucker at zip.com.au changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |627 nThis| | Status|NEW |ASSIGNED ------- Additional Comments From dtucker at zip.com.au 2003-08-24 11:51 ------- Has the new PAM code fixed this? I haven't tried it for a long time. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Aug-29 13:06 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-08-29 23:06 ------- I just tried with CVS version as of today on HP-UX 11.00. No, unfortunately it doesn't even get that far. The issue from [BUG 419] is still unresolved, meaning that PAM session setup breaks with trusted mode and privsep: fatal: PAM: pam_open_session(): General Commercial Security error This can be observed with PAMAuthenticationViaKbdInt enabled, while "traditional" password authentication got broken entirely with trusted mode and privsep. Correct passwords are being rejected: Failed password for ... When turning off trusted mode the same passwords get accepted again (and session setup succeeds). ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Aug-29 14:46 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-08-30 00:46 ------- Created an attachment (id=375) --> (http://bugzilla.mindrot.org/attachment.cgi?id=375&action=view) Ported version of Dan's original session setup patch With the attached version of Dan Wanek's original session setup patch I could at least get login to work again with trusted mode and pivsep. (I also had to unwrap the struct initialization of sshpam_conv in auth-pam.c, as the compiler didn't accept the current construct.) However, it still looks a bit strange. Password authentication only works with ChallengeResponseAuthentication(?) enabled. Otherwise correct passwords are being rejected. With proto 2 I'm getting the usual password prompt from PAM. With proto 1 it looks like challenge response (but both prompts popping up immediately) Password: Response: where authentication succeeds after typing the regular user password as "Response". ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Aug-29 22:41 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From dtucker at zip.com.au 2003-08-30 08:41 ------- Will that patch (attachment #375) cause other PAM-using platforms to cough up a hairball? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-01 06:40 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 michael_steffens at hp.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #375 is|0 |1 obsolete| | ------- Additional Comments From michael_steffens at hp.com 2003-09-01 16:40 ------- Created an attachment (id=376) --> (http://bugzilla.mindrot.org/attachment.cgi?id=376&action=view) Corrected port of Dan's original session setup patch Sorry, with (attachment #375) I introduced a stupid bug, making the initialization of sshpam_conv conditional (which didn't show up because USE_POSIX_THREADS was not defined). The attached version has this one corrected. When I last tested Dan's proposed modifications on Solaris and Linux, these didn't hickup. Would prefer someone more familiar with these platforms to verify, though. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-01 06:51 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From djm at mindrot.org 2003-09-01 16:51 ------- (From update of attachment 376)>--- auth-pam.c-orig Tue Aug 26 03:58:16 2003 >+++ auth-pam.c Mon Sep 1 08:04:13 2003 >@@ -199,10 +199,15 @@ > { > struct pam_ctxt *ctxt = ctxtp; > Buffer buffer; >- struct pam_conv sshpam_conv = { sshpam_thread_conv, ctxt }; >+ struct pam_conv sshpam_conv; > #ifndef USE_POSIX_THREADS > const char *pam_user; >+#endif >+ >+ sshpam_conv.conv = sshpam_thread_conv; >+ sshpam_conv.appdata_ptr = ctxt;I don't understand this part of the patch. Why does break the initialisation from the declaration?>+#ifndef USE_POSIX_THREADSI'm not sure which version you are diffing against, but CVS HEAD already has this test.> #if defined(USE_PAM) > if (options.use_pam) { >- do_pam_session(s->pw->pw_name, NULL); > do_pam_setcred(1); > if (is_pam_password_change_required()) > packet_disconnect("Password change required but no " >@@ -561,7 +560,7 @@ > > #if defined(USE_PAM) > if (options.use_pam) { >- do_pam_session(s->pw->pw_name, s->tty); >+ do_pam_set_tty(s->tty); > do_pam_setcred(1); > } > #endif >@@ -1235,6 +1234,7 @@ > */ > if (options.use_pam) > do_pam_setcred(0); >+ do_pam_session(pw->pw_name,NULL);This is missing braces after the "if" statement. I.e if (options.use_pam) { do_pam_setcred(0); do_pam_session(pw->pw_name,NULL); } I agree that do_pam_session makes more sense is setusercontext, but if we split the PAM_TTY setting, then we should remove do_pam_session's second argument entirely. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-01 07:24 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-09-01 17:24 -------> ------- Additional Comments From djm at mindrot.org 2003-09-01 16:51 ------- > (From update of attachment 376) > >>--- auth-pam.c-orig Tue Aug 26 03:58:16 2003 >>+++ auth-pam.c Mon Sep 1 08:04:13 2003 >>@@ -199,10 +199,15 @@ >>{ >> struct pam_ctxt *ctxt = ctxtp; >> Buffer buffer; >>- struct pam_conv sshpam_conv = { sshpam_thread_conv, ctxt }; >>+ struct pam_conv sshpam_conv; >>#ifndef USE_POSIX_THREADS >> const char *pam_user; >>+#endif >>+ >>+ sshpam_conv.conv = sshpam_thread_conv; >>+ sshpam_conv.appdata_ptr = ctxt; > > > I don't understand this part of the patch. Why does break the initialisation > from the declaration?To be honest, I don't know. Compiler refused it with error 1521: Incorrect initialization.> > >>+#ifndef USE_POSIX_THREADS > > > I'm not sure which version you are diffing against, but CVS HEAD already has > this test.Yes, but I erranously moved initialization inside the #ifndef block when wanting to get it past the declaration of pam_user. Correction was to split the #ifndef, and put the initialization in between.> > > >>#if defined(USE_PAM) >> if (options.use_pam) { >>- do_pam_session(s->pw->pw_name, NULL); >> do_pam_setcred(1); >> if (is_pam_password_change_required()) >> packet_disconnect("Password change required but no " >>@@ -561,7 +560,7 @@ >> >>#if defined(USE_PAM) >> if (options.use_pam) { >>- do_pam_session(s->pw->pw_name, s->tty); >>+ do_pam_set_tty(s->tty); >> do_pam_setcred(1); >> } >>#endif >>@@ -1235,6 +1234,7 @@ >> */ >> if (options.use_pam) >> do_pam_setcred(0); >>+ do_pam_session(pw->pw_name,NULL); > > > This is missing braces after the "if" statement. I.e > > if (options.use_pam) { > do_pam_setcred(0); > do_pam_session(pw->pw_name,NULL); > }Yep, another stupid bug of mine :(. Thanks for catching. (This also didn't show up when testing, because options.use_pam was true, of course.)> > I agree that do_pam_session makes more sense is setusercontext, but if we split > the PAM_TTY setting, then we should remove do_pam_session's second argument > entirely.Also agreed. (I used Dan's original modifications as they were, and these were presumably meant to modify at little as possible. But there is only one invokation of do_pam_session left, not using the second argument.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-01 08:31 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 michael_steffens at hp.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #376 is|0 |1 obsolete| | ------- Additional Comments From michael_steffens at hp.com 2003-09-01 18:31 ------- Created an attachment (id=377) --> (http://bugzilla.mindrot.org/attachment.cgi?id=377&action=view) 3rd version port of Dan's original session setup patch Now a version taking djm's correction and suggestion into account. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-01 15:06 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-09-02 01:06 ------- Tried to find where the strange password authentication behaviour mentioned in comment #22 comes from, and why plain old password authentication fails in HP-UX trusted mode. Maybe this got me a bit closer to how the new code works. :) Apparently it's falling back to non-PAM authentication for plain old password authentication (the one where the client prompts "user at host's password:"). This fails in trusted mode, because DISABLE_SHADOW is defined for all versions of HP-UX, thus getspnam is not being used to retrieve the real pw hash. Instead the '*' from /etc/passwd is being used. By enabling shadow this can be fixed. I have tried it and it worked. On the other hand, with proto 1, TIS authentication has precedence over password authentication, and it actually works using sshpam_device. PAM happens to generate the challenge "Password:", and succeeds when getting the correct password on the prompt "Response:". In case password via TIS fails (for example because the user was confused by the prompts), traditional password authentication, bypassing PAM, is being tried. Is this correct and the intended order? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-02 13:19 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 djm at mindrot.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From djm at mindrot.org 2003-09-02 23:19 ------- very similar patch applied, thanks. Please file a separate bug for the HAVE_SHADOW issue ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-02 14:39 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-09-03 00:39 ------- Hi Damien, thanks for applying! However, this modification only solves the problem of getting session set up at all with privsep in trusted mode, but not yet changing expired passwords. (The one being prerequisite to perform the other.) This fix would rather apply to BUG #419, which is marked resolved/duplicate of BUG #83. However, I'm having no idea whether they are related... Michael ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-02 14:47 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From Todd.Bowden at atosorigin.com 2003-09-03 00:47 ------- Didnt Patch 162 fix all this? I have OpenSSH 3.5p1 working on a HP-UX 11 trusted system in privelage seperation mode with password aging and it works like a charm. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
bugzilla-daemon at mindrot.org
2003-Sep-02 15:03 UTC
[Bug 423] Workaround for pw change in privsep mode (3.5.p1)
http://bugzilla.mindrot.org/show_bug.cgi?id=423 ------- Additional Comments From michael_steffens at hp.com 2003-09-03 01:03 ------- It did, besides the additional suid ssh-chauthtok-helper did not get accepted. The more elegant approach should be enabled by new PAM code, but is apparently not active yet. (unless, beat me, I missed something. It didn't work when I tried yesterday.) ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.