openssh unix dev - Sep 2006 - Weird TZ Behavior in 4.1p1 and 4.3p2 on AIX

Hi,

 

I am using PAM authentication on 3.8p1.  In my PAM auth module I can
turn on debug logging that includes a timestamp in the form "mm/dd/yy
hh:mm:ss".  Life is good.

 

I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication
in addition to keyboard-interactive.  I have compiled both 4.1p1 and
4.3p2 and the PAM authentication for both methods works fine in both
releases, but I have a weird annoyance in the logging.  The timestamp
code appears to be ignoring the TZ setting.  Here is a snippet from the
logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged
in ~ 9:30 this morning:

 

09/12/06 09:34:52 username hostname.xxxxx.com

09/12/06 09:35:02 username authenticating locally

09/12/06 09:35:02 username local authentication succeeded

09/12/06 13:35:21 username hostname.xxxxx.com

09/12/06 13:35:25 username authenticating locally

09/12/06 13:35:25 username local authentication succeeded

09/12/06 09:36:07 username hostname.xxxxx.com

09/12/06 09:36:12 username authenticating locally

 

I found that commenting out "environ[0] = NULL;" in pam-auth.c fixed
the
TZ problem, but created others.

 

Any suggestions?

 

Scott Strickler 

 



***** Please note: The Sender of this email is either a Contractor or Vendor of
Lowe's Companies, Inc. and is not an employee or agent of Lowe's
Companies Inc. *****
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi,

 

I am using PAM authentication on 3.8p1.  In my PAM auth module I can
turn on debug logging that includes a timestamp in the form "mm/dd/yy
hh:mm:ss".  Life is good.

 

I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication
in addition to keyboard-interactive.  I have compiled both 4.1p1 and
4.3p2 and the PAM authentication for both methods works fine in both
releases, but I have a weird annoyance in the logging.  The timestamp
code appears to be ignoring the TZ setting.  Here is a snippet from the
logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged
in ~ 9:30 this morning:

 

09/12/06 09:34:52 username hostname.xxxxx.com

09/12/06 09:35:02 username authenticating locally

09/12/06 09:35:02 username local authentication succeeded

09/12/06 13:35:21 username hostname.xxxxx.com

09/12/06 13:35:25 username authenticating locally

09/12/06 13:35:25 username local authentication succeeded

09/12/06 09:36:07 username hostname.xxxxx.com

09/12/06 09:36:12 username authenticating locally

 

I found that commenting out "environ[0] = NULL;" in pam-auth.c fixed
the
TZ problem, but created others.

 

Any suggestions?

 

Scott Strickler 

 



***** Please note: The Sender of this email is either a Contractor or Vendor of
Lowe's Companies, Inc. and is not an employee or agent of Lowe's
Companies Inc. *****

On Tue, Sep 12, 2006 at 10:37:58AM -0400, Strickler, Scott - Scott F
wrote:
> I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication
> in addition to keyboard-interactive.  I have compiled both 4.1p1 and
> 4.3p2 and the PAM authentication for both methods works fine in both
> releases, but I have a weird annoyance in the logging.  The timestamp
> code appears to be ignoring the TZ setting.  Here is a snippet from the
> logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged
> in ~ 9:30 this morning:

Maybe we should save and restore TZ, like the following?  (untested)

Index: auth-pam.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh/auth-pam.c,v
retrieving revision 1.140
diff -u -p -r1.140 auth-pam.c
--- auth-pam.c	1 Sep 2006 05:38:36 -0000	1.140
+++ auth-pam.c	12 Sep 2006 22:13:49 -0000
@@ -437,10 +437,16 @@ sshpam_thread(void *ctxtp)
 	u_int i;
 	const char *pam_user;
 	const char **ptr_pam_user = &pam_user;
+	char *tz = getenv("TZ");
 
 	pam_get_item(sshpam_handle, PAM_USER,
 	    (sshpam_const void **)ptr_pam_user);
+
 	environ[0] = NULL;
+	if (tz != NULL)
+		if (putenv("TZ", tz) == -1)
+			error("PAM: could not set TZ environment: %s",
+			    strerror(errno));
 
 	if (sshpam_authctxt != NULL) {
 		setproctitle("%s [pam]",

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, Sep 12, 2006 at 10:37:58AM -0400, Strickler, Scott - Scott F
wrote:
> I want to upgrade from 3.8p1 so I can use PAM for PasswordAuthentication
> in addition to keyboard-interactive.  I have compiled both 4.1p1 and
> 4.3p2 and the PAM authentication for both methods works fine in both
> releases, but I have a weird annoyance in the logging.  The timestamp
> code appears to be ignoring the TZ setting.  Here is a snippet from the
> logfile where I changed back and forth from 3.8p1 and 4.1p1 as I logged
> in ~ 9:30 this morning:

Maybe we should save and restore TZ, like the following?  (untested)

Index: auth-pam.c
==================================================================RCS file:
/usr/local/src/security/openssh/cvs/openssh/auth-pam.c,v
retrieving revision 1.140
diff -u -p -r1.140 auth-pam.c
--- auth-pam.c	1 Sep 2006 05:38:36 -0000	1.140
+++ auth-pam.c	12 Sep 2006 22:13:49 -0000
@@ -437,10 +437,16 @@ sshpam_thread(void *ctxtp)
 	u_int i;
 	const char *pam_user;
 	const char **ptr_pam_user = &pam_user;
+	char *tz = getenv("TZ");
 
 	pam_get_item(sshpam_handle, PAM_USER,
 	    (sshpam_const void **)ptr_pam_user);
+
 	environ[0] = NULL;
+	if (tz != NULL)
+		if (putenv("TZ", tz) == -1)
+			error("PAM: could not set TZ environment: %s",
+			    strerror(errno));
 
 	if (sshpam_authctxt != NULL) {
 		setproctitle("%s [pam]",

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.