The build system is hppa1.1-hp-hpux10.20 and openssh is version 3.4p1. The w (uptime) command indicates a user is still logged in after logout. The problem wasn't present in 3.1p1 even though writing to utmp is disabled. Other commands such as who and last generate correct results. /dev/pts/* appear to be correctly released. Looking at config.h, I noticed that writing to utmp was disabled: /* Define if you don't want to use utmp */ #define DISABLE_UTMP 1 Commenting this out and rebuilding, fixed the problem. Disabling writing to wtmp seems to be the default (ie, I didn't disable it when running configure).
*** Bug 352 has been marked as a duplicate of this bug. ***
I "trace"ed a little bit: * on login, both /etc/utmpx and /etc/utmp are updated with the login- information * on logout, only /etc/utmpx is updated who (=w) only reads /etc/utmp, so that it gets wrong login information. This applies to today's CVS (2002/07/18). As far as I have added debugging statements, utmpx_write_library() is called for both login and logout. According to the manual page, pututxline() should translate the utmpx entry into an utmp entry and also update utmp accordingly. This only seems to happen for login, not for logout. As far as I have looked over the code, I do not understand, why utmpx_perform_logout() calls line_abbrevname() again (conditionally), as the same code is also part of construct_utmpx(), isn't it? Also utx.ut_type should have been set before unconditionally in construct_utmpx(). So much for now. It seems that the rest is somewhere buried inside pututxline() which does not provide too much diagnostics... Oh, I just see, that in utmpx_perform_login(), there is called utmpx_write_direct(li, &ut) for the case of !UTMPX_USE_LIBRARY (note the "&ut" instead of "&utx", but it does not apply here anyway).
More inputs: The problem appears only with privilege separation enabled, it does not appear without privsep. I have added some debugging information and it seems, that the difference between privsep and not is, that without privsep the utmp(x) modifications are performed by 2 processes: the login is performed by the process being the child (later becoming the shell) while the logout is handled by the sshd process. With privsep enabled, both login and logout are handled by the same sshd process (thus pututxline() is called from the same process). I don't know, in how far this influences the process, as the pututxline() function is not open source. Maybe some state information is incorrectly handled, such that the second pututxline() process does handle /etc/utmpx but then has a problem with the /etc/utmp update. This is however just a guess until know. For what it seems to me now, it is more a problem that is caused by HP-UX than a problem of OpenSSH.
I did not find any further information with respect to this problem. It seems to be a bug in HP's pututxline() implementation. From feedback it seems, that this problem only affects 10.20, HP-UX 11 doesn't seem to have this problem. As a workaround, I have modified config.h to remove DISABLE_UTMP. This way both utmp and utmpx are updated and it does not seem to hurt (after some short tests). DISABLE_UTMP is enforced by "configure" for HP-UX 10.20. Are there any sideeffects to be expected? Otherwise one could consider to remove DISABLE_UTMP from the default settings for HP-UX 10.20.
Created attachment 379 [details] Remove DISABLE_UTMP from HP-UX 10.x Are we going to do something like this? Anyone with HP-UX 10.x experience want to comment?
The change works around the problem on HP-UX 10.20. I have re-checked the latest libc patch (PHCO_26158) and the problem is still around. As HP-UX 10.20 has reached its official "end-of-life" I do not expect the problem to be fixed from HP's side anymore.
Comment on attachment 379 [details] Remove DISABLE_UTMP from HP-UX 10.x ok by me
Applied, thanks.
Verified correct operation with portable CVS as of 12 Feb 2004.
Mass change of VERIFIED bugs to CLOSED