Bug 464 - sshd seems to corrupt the wtmpx
Summary: sshd seems to corrupt the wtmpx
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: -current
Hardware: UltraSPARC Solaris
: P4 minor
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks: 793
  Show dependency tree / graph
 
Reported: 2003-01-09 01:11 AEDT by Paul Smith
Modified: 2004-04-14 12:24 AEST (History)
1 user (show)

See Also:

Attachments
Use updwtmpx for 64bit platforms that support it (no configure.ac) (466 bytes, text/plain)
2003-09-27 00:41 AEST, Ben Lindstrom 		dtucker: ok+
Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Smith 2003-01-09 01:11:45 AEDT 
Starting with an empty wtmpx.
I ssh to the machine. 
I then do last and get 
pas       pts/6                        Thu Jan  1 01:00   still logged in
Using fwtmp to convert the wtmp file to asci I get
pas                              ts/6 pts/6                                 1886
 7 0000 0000 0 1042034068 0 0  Thu Jan  1 01:00:00 1970

If I log in using ssh or on the console then these do not appear in last.
Comment 1 Paul Smith 2003-01-09 02:11:50 AEDT 
This is apparently a bug with compiling in 64 bit. 
David foster saw this. 
http://www.sunmanagers.org/pipermail/summaries/2002-October/004018.html
Comment 2 Paul Smith 2003-01-09 04:07:34 AEDT 
Checked against latest snapshot.Problem is still there.
Comment 3 Ben Lindstrom 2003-01-09 04:46:57 AEDT 
I really want to know why people are compiling software in 64bit when there is 
zero logical reason.  Nor any physical gain.   A lot of 64bit platforms have 
issues with their [uw]tmp[.] files while crossing from 32bit to 64bit due to 
alignments and such.  However, no one has bother to give me a good reason why 
the code should be #ifdef/#endif to hell to support a behavior.
Comment 4 Paul Smith 2003-01-09 19:29:04 AEDT 
It is simple laziness. We have applications that require 64 bit. We therefor
have to have to libraries compiled in 64 bit. Rather than build two copies of
all the libraries we build everything in 64 bit.
Comment 5 Petter Reinholdtsen 2003-04-03 03:03:26 AEST 
I see the same problem on IA64 HP/UX 11.22.  Is there any workaround when
openssl need to be 64 bit?
Comment 6 Ben Lindstrom 2003-09-27 00:41:40 AEST 
Created attachment 471 [details]
Use updwtmpx for 64bit platforms that support it (no configure.ac)

add a "#define HAVE_UPDWTMPX 1" into your config.h and apply this patch.

Does this solve your problem?
Comment 7 Petter Reinholdtsen 2003-09-29 21:48:36 AEST 
The patch solved the problem on HP/UX 11.22 for me. :)
Comment 8 Darren Tucker 2004-02-10 16:21:14 AEDT 
Comment on attachment 471 [details]
Use updwtmpx for 64bit platforms that support it (no configure.ac)

Tests OK (with the appropriate addition to configure) on Solaris 8 (32 bit),
HP-UX 11.00 (32&64 bit).  AIX doesn't have updwtmpx.
Comment 9 Ben Lindstrom 2004-02-10 16:26:27 AEDT 
I can confirm this does work under Solaris 9.  As long as it it detected I'm ok
with it.
Comment 10 Darren Tucker 2004-02-10 16:51:03 AEDT 
Patch applied, thanks.
Comment 11 Damien Miller 2004-04-14 12:24:18 AEST 
Mass change of RESOLVED bugs to CLOSED