openssh-2.9p2 and IRIX utmp problems
Kevin Taylor
I've been through some of this with someone on the openssh team that had
rewritten a lot of the openssh wtmp handling, but I don't think we came
to a good conclusion on this issue.
On an IRIX system, openssh is not handling the deletion and creation of
wtmp/utmp entries well. For example if you look who's on the system, and
on what tty, you might see something like this:
user1 q88 hostname.org 16Aug01 16:28 7:29 1 -ksh
If you do who -a (to check utmpx) looking at that particular tty (q88):
user2 ttyq88 Aug 15 14:34 16:28 2094056 id= q88 term=255
exit=2 (host2)
user1 + ttyq88 Aug 16 13:59 16:28 2277427 (hostname.org)
It appears to be offering the information that user1 is currently logged
in.....but why is user2's information still there? The problem that this
effectively causes is that some system programs, like 'logname' for
example, will display the incorrect username.
user1% logname
user2
The problem is that the user2 entry will never go away unless the system
is completely rebooted.
I believe this could be caused by someone logging in through openssh,
then launching an xterm....then exiting the xterm.
This is a serious problem because it means that we cannot upgrade, or
make modifications to ssh configurations without taking the entire
system down. If we restart sshd, then all those users that are logged in
will go into limbo and no one that logs in afterward will have the
correct utmp info.
Do you have any suggestions on how to fix this?
Kevin Taylor
I actually found something out which doesn't really fix the problem.
the /usr/bin/logname program will read utmp and just print the first
occurance of your tty name....whether or not it's you.
So, if you type this:
user2% who -a |grep ttyq55
user1 ttyq55 Jul 23 17:28 . 25827 id= q55 term=255
exit=2 (hostname.org)
user2 + ttyq55 Sep 5 09:47 . 5139684 (hostname.org)
user2% logname
user1
It's printing user1 because that's the first entry returned in the utmp
file.
If I log in again, and get this situation:
user2% who -a |grep ttyq56
user2 + ttyq56 Sep 5 09:47 . 3086502 (hostname.org)
user3 ttyq56 Aug 31 17:54 . 4469380 id= q56
term=255 exit=2
user2% logname
user2
So, user2 comes first on this tty, so logname assumes that's correct.
I firmly believe that the openssh code is broken, but also that logname
isn't really robustly written. Wouldn't it be better to check to see if
there is something in the second field of this output? Notice the "+" in
the second field. That means the terminal is writable, "-" means it's
not, and "?" means the state is undetermined.....if it's empty, wouldn't
that mean that no one is logged in there? So simply checking for the
existence of +, -, or ? should tell you that someone is actively on that
tty correct?
Mike O'Connor
Kevin Taylor <n...@nowhere.org> wrote:
:
:I've been through some of this with someone on the openssh team that had
I don't see this problem with 2.9p2 on IRIX 6.2 or 2.5.1p2 on IRIX
6.5.{reasonably current}, on systems where OpenSSH and the console
are the only access mechanisms. Might this be a particular config
issue of some sort? Does chkutent fix this?
--
Michael J. O'Connor | WWW: http://dojo.mi.org/~mjo/ | Email: m...@dojo.mi.org
Royal Oak, Michigan | (has my PGP & Geek Code info) | Phone: +1 248-427-4481
=--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"You know what we need, Hobbes? We need an attitude." -Calvin
Kevin Taylor
>
> I don't see this problem with 2.9p2 on IRIX 6.2 or 2.5.1p2 on IRIX
> 6.5.{reasonably current}, on systems where OpenSSH and the console
> are the only access mechanisms. Might this be a particular config
> issue of some sort? Does chkutent fix this?
>
Actually I believe the culprit was users running xterms after logging in
through ssh. For some reason sgi's xterm does not handle utmp well, or
at least in the same way that openssh did, so there was a conflict.
I got into some communication with the engineer that wrote most of the
openssh utmp code, and he offered some patches for it that fixed my
problem.
I guess I'm allowed to post the patches....it's open sourced (this is
against the openssh-2.9p2 source).
--- openssh-2.9p2.orig/config.h.in Sun Jun 17 04:09:47 2001
+++ openssh-2.9p2/config.h.in Wed Sep 5 19:11:41 2001
@@ -102,6 +102,9 @@
/* Define if you want IRIX kernel jobs */
#undef WITH_IRIX_JOBS
+/* Define if the tty id (abbreviated name) in *tmp strips tty */
+#undef WITH_ABBREV_NO_TTY
+
/* Location of random number pool */
#undef RANDOM_POOL
--- openssh-2.9p2.orig/configure Sun Jun 17 04:09:50 2001
+++ openssh-2.9p2/configure Wed Sep 5 19:12:44 2001
@@ -1672,6 +1672,10 @@
#define WITH_IRIX_AUDIT 1
EOF
+ cat >> confdefs.h <<\EOF
+#define WITH_ABBREV_NO_TTY 1
+EOF
+
echo $ac_n "checking for jlimit_startjob""... $ac_c" 1>&6
echo "configure:1677: checking for jlimit_startjob" >&5
if eval "test \"`echo '$''{'ac_cv_func_jlimit_startjob'+set}'`\" =
set"; then
--- openssh-2.9p2.orig/configure.in Mon May 28 17:21:44 2001
+++ openssh-2.9p2/configure.in Wed Sep 5 19:13:06 2001
@@ -111,6 +111,7 @@
AC_DEFINE(WITH_IRIX_ARRAY)
AC_DEFINE(WITH_IRIX_PROJECT)
AC_DEFINE(WITH_IRIX_AUDIT)
+ AC_DEFINE(WITH_ABBREV_NO_TTY)
AC_CHECK_FUNC(jlimit_startjob, [AC_DEFINE(WITH_IRIX_JOBS)])
no_libsocket=1
no_libnsl=1
--- openssh-2.9p2.orig/loginrec.c Tue May 8 20:34:33 2001
+++ openssh-2.9p2/loginrec.c Wed Sep 5 19:09:00 2001
@@ -563,6 +563,11 @@
if (strncmp(src, "/dev/", 5) == 0)
src += 5;
+#ifdef WITH_ABBREV_NO_TTY
+ if (strncmp(src, "tty", 3) == 0)
+ src += 3;
+#endif
+
len = strlen(src);
if (len > 0) {
Mike O'Connor
Kevin Taylor <n...@nowhere.org> wrote:
:> I don't see this problem with 2.9p2 on IRIX 6.2 or 2.5.1p2 on IRIX
:> 6.5.{reasonably current}, on systems where OpenSSH and the console
:> are the only access mechanisms. Might this be a particular config
:> issue of some sort? Does chkutent fix this?
:
:
:Actually I believe the culprit was users running xterms after logging in
:through ssh. For some reason sgi's xterm does not handle utmp well, or
:at least in the same way that openssh did, so there was a conflict.
Ahhhh... <whaps self> That's what I get for making xterm not suid root
out of a sense of paranoia. :)
:I got into some communication with the engineer that wrote most of the
:openssh utmp code, and he offered some patches for it that fixed my
:problem.
:
:I guess I'm allowed to post the patches....it's open sourced (this is
:against the openssh-2.9p2 source).
I take it these are slated to go into a future OpenSSH release?
Kevin Taylor
> In article <3B979A7D...@nowhere.org>,
> Kevin Taylor <n...@nowhere.org> wrote:
> :> I don't see this problem with 2.9p2 on IRIX 6.2 or 2.5.1p2 on IRIX
> :> 6.5.{reasonably current}, on systems where OpenSSH and the console
> :> are the only access mechanisms. Might this be a particular config
> :> issue of some sort? Does chkutent fix this?
> :
> :
> :Actually I believe the culprit was users running xterms after logging in
> :through ssh. For some reason sgi's xterm does not handle utmp well, or
> :at least in the same way that openssh did, so there was a conflict.
>
> Ahhhh... <whaps self> That's what I get for making xterm not suid root
> out of a sense of paranoia. :)
>
> :I got into some communication with the engineer that wrote most of the
> :openssh utmp code, and he offered some patches for it that fixed my
> :problem.
> :
> :I guess I'm allowed to post the patches....it's open sourced (this is
> :against the openssh-2.9p2 source).
>
> I take it these are slated to go into a future OpenSSH release?
>
I think it will be going into the release....I hope.
Roberto Mansoni
irix 4. At the University of Toronto, John Chee Wah and Ken Lalonde
wrote something years ago to walk through the utmp file and--as I
recall--look for dead processes and use pututent to write a null to
the ut_user field of the utmp structure. I invoked this (via crontab)
until irix 6 but maybe I shouldn't have given it up. Should chkutent
do something like this?
Recently we had a situation in which someone su'd to root sent email
to another user (joe). The email looked like it had been sent by
another user. I used my own dumputmpx program to check it out (forgot
all about who -a) which showed this:
olduser 16 ttyq16 34470983 DEAD_PROCESS Tue Sep 11
23:42:44 2001 term=0, exit=2
newuser q16 ttyq16 38747487 USER_PROCESS Thu Sep 13
15:35:22 2001
newuser kept his window open for several days until--as I was still
examining the situation--the olduser process disappeared. Chkutent
didn't send email about any changes.
Thanks for the openssh patches. I'll try them out.
Roberto
Kevin Taylor
I noticed something that may or may not even be related to this, but
when you exit an xterm session, who -a always shows an error code of 2.
Whether or not you exit the session properly. Of course, if you run
xterm without updating utmp, then there's no problem.