Bug 419 - HP-UX PAM problems with 3.5p1
Summary: HP-UX PAM problems with 3.5p1
Status: CLOSED DUPLICATE of bug 83
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: -current
Hardware: HPPA HP-UX
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-21 17:45 AEST by Michael Steffens
Modified: 2004-04-14 12:24 AEST (History)
0 users

See Also:


Attachments
Patches for making privsep run with HP-UX trusted mode amd avoid credentials deletion errors (2.46 KB, patch)
2002-10-21 17:54 AEST, Michael Steffens
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Steffens 2002-10-21 17:45:26 AEST
Hello,

thanks very much for releasing OpenSSH 3.5p1!

Unfortunately there are still problems with HP-UX PAM. The attached patch
addresses a known one, and one that I haven't found any HP-UX related
postings for.

1) pam_open_session() failure with privilege separation and HP-UX running
   in trusted mode.

This is known and Dan Wanek has posted a patch for 3.4p1 fixing it on
July 16:

  http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102682619813556&w=2

It has got quite good comments and works fine here, but hasn't made it
into 3.5p1.  Why?  I merged it into 3.5p1 (which exhibits the same problem)
manually, and it still does fine, tested on 11.00 and 11.11.

(If you decide to merge it into official source trees please remember
to give credits to Dan rather than me for this portion :)

2) Failed deletion of credentials in do_pam_cleanup_proc()

This issue seems to be old (observed with 3.1p1, 3.4p1, and 3.5p1 in
both trusted and non-trusted mode, both with or without privilege
separation).  I'm not sure how critical this is, as 3.1p1 seems to
run happily for many months without a visible impact, but error
messages still look quite odd.  On session termination sshd reports

  debug1: Cannot delete credentials[9]: Authentication failed

in debug mode. ("Authentication failed" is reported with privsep.
Without the reason given is "Permission denied".)

When turning on debug logging in syslog, the messages corresponding
to session termination are

  PAM: pam_close_session()
  PAM: load_function: successful load of pam_sm_close_session
  PAM: pam_setcred: error Authentication failed
  PAM: pam_end(): status = Authentication failed

Strange enough that pam_end() is reported to have failed too, despite
the sshd apparently got PAM_SUCCESS returned!  I tried the system native
login program to see how it is scheduling PAM session cleanup.  Not at
all, neither pam_close_session() nor pam_setcred() are being called.
Only pam_end(), which is reported to be successful in syslog debug log.

When omitting credentials deletion in sshd, and relying on pam_end() to do
that implicitly, errors triggered by the daemon vanish, both with and
without privsep:

  PAM: pam_close_session()
  PAM: load_function: successful load of pam_sm_close_session
  PAM: pam_end(): status = Success

So it seems to be preferrable to skip credentials deletion on HP-UX...

Cheers!
Michael


diff -u -r openssh-3.5p1/auth-pam.c openssh-3.5p1a/auth-pam.c
--- openssh-3.5p1/auth-pam.c	Sun Jul 28 22:24:08 2002
+++ openssh-3.5p1a/auth-pam.c	Wed Oct 16 15:00:01 2002
@@ -186,12 +186,14 @@
 			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
 	}
 
+#ifndef __hpux
 	if (__pamh && creds_set) {
 		pam_retval = pam_setcred(__pamh, PAM_DELETE_CRED);
 		if (pam_retval != PAM_SUCCESS)
 			debug("Cannot delete credentials[%d]: %.200s", 
 			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
 	}
+#endif
 
 	if (__pamh) {
 		pam_retval = pam_end(__pamh, pam_retval);
@@ -299,6 +301,18 @@
 		    pam_retval, PAM_STRERROR(__pamh, pam_retval));
 
 	session_opened = 1;
+}
+
+/* Set the TTY after session is open */
+void do_pam_set_tty(const char *ttyname) {
+	int pam_retval;
+	if (ttyname != NULL) {
+		debug("PAM setting tty to \"%.200s\"", ttyname);
+		pam_retval = pam_set_item(__pamh, PAM_TTY, ttyname);
+		if (pam_retval != PAM_SUCCESS)
+			fatal("PAM set tty failed[%d]: %.200s",
+			    pam_retval, PAM_STRERROR(__pamh, pam_retval));
+	}
 }
 
 /* Set PAM credentials */
diff -u -r openssh-3.5p1/auth-pam.h openssh-3.5p1a/auth-pam.h
--- openssh-3.5p1/auth-pam.h	Tue Jul 23 02:44:07 2002
+++ openssh-3.5p1a/auth-pam.h	Wed Oct 16 10:00:40 2002
@@ -39,6 +39,7 @@
 int do_pam_authenticate(int flags);
 int do_pam_account(char *username, char *remote_user);
 void do_pam_session(char *username, const char *ttyname);
+void do_pam_set_tty(const char *ttyname);
 void do_pam_setcred(int init);
 void print_pam_messages(void);
 int is_pam_password_change_required(void);
diff -u -r openssh-3.5p1/session.c openssh-3.5p1a/session.c
--- openssh-3.5p1/session.c	Thu Sep 26 02:38:50 2002
+++ openssh-3.5p1a/session.c	Wed Oct 16 15:01:40 2002
@@ -454,7 +454,6 @@
 	session_proctitle(s);
 
 #if defined(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 "
@@ -581,7 +580,7 @@
 	ttyfd = s->ttyfd;
 
 #if defined(USE_PAM)
-	do_pam_session(s->pw->pw_name, s->tty);
+	do_pam_set_tty(s->tty);
 	do_pam_setcred(1);
 #endif
 
@@ -1238,6 +1237,13 @@
 		 * Reestablish them here.
 		 */
 		do_pam_setcred(0);
+
+		/*
+		 * We need to open the session here because PAM on HP-UX does not
+		 * work after the call to permanently_set_uid.
+		 */
+		do_pam_session(pw->pw_name,NULL);
+
 # endif /* USE_PAM */
 # if defined(WITH_IRIX_PROJECT) || defined(WITH_IRIX_JOBS) ||
defined(WITH_IRIX_ARRAY)
 		irix_setusercontext(pw);
Comment 1 Michael Steffens 2002-10-21 17:54:19 AEST
Created attachment 157 [details]
Patches for making privsep run with HP-UX trusted mode amd avoid credentials deletion errors

Sorry, being new to bugzilla I didn't know that attachments will be asked for
in the next form. Please excuse duplication in description!

!! Majority of this patch is actually by Dan Wanek !! :
  http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=102682619813556&w=2
Comment 2 Ben Lindstrom 2002-11-02 03:36:52 AEDT
please don't open up multiple entries for a single bug

*** This bug has been marked as a duplicate of 423 ***
Comment 3 Damien Miller 2003-03-22 08:29:52 AEDT
This is more like bug #83, but please list only one bug per report in future.

*** This bug has been marked as a duplicate of 83 ***
Comment 4 Damien Miller 2004-04-14 12:24:18 AEST
Mass change of RESOLVED bugs to CLOSED