openssh unix dev - Jul 2002 - Irix UseLogin wtmp/utmp bug

I am using the "UseLogin yes" configuration parameter to call the
/usr/bin/login program on SGI Irix, (we are using Irix version
6.5.13).  I do this because the SGI login program is AFS awhere and
checks out a token for you and I do not want to compile the Kerberos
version of sshd, (it is to messy for me to support).

Everything seems to work fine accept the wtmp(x) and utmp(x) files do
not get updated? The problem existed in openssh 3.0.2 I just upgraded
to 3.4 and still have the problem. Here is what I have found, if anyone
has any info that would be great else I will have to live with this:


The login program is execl'd in the sesssion.c file using the execl()
call:

----------

static void
launch_login(struct passwd *pw, const char *hostname)
{
char *env_init[] = {"MYENV=null", NULL};
        /* Launch login(1). */

        fprintf(stderr, "X11 forwarding not supported with IRIX
login.\n");
        fprintf(stderr, "Must enter password again to get AFS
token,\n");
        /* execl(LOGIN_PROGRAM, "login", "-h", hostname, */
        execl(LOGIN_PROGRAM, "login",
#ifdef xxxLOGIN_NEEDS_TERM
                    (s->term ? s->term : "unknown"),
#endif /* LOGIN_NEEDS_TERM */
#ifdef LOGIN_NO_ENDOPT
            /* "-p", "-f", pw->pw_name, (char *)NULL); */
            pw->pw_name, (char *)NULL);
#else
            /* "-p", "-f", "--", pw->pw_name,
(char *)NULL); */
             pw->pw_name, (char *)NULL);
#endif

----------

Note I made a few changes here since the SGI login program only
supports the following options, (from the sgi man page):

login(1)

NAME
     login - sign on

SYNOPSIS
     login [ -d device ] [ name [ environ ... ]]




After the ifdef's are applied above login gets called as:

execl(LOGIN_PROGRAM, "login",pw->pw_name, (char *)NULL);

Which equates to "/usr/bin/login user_name".


When a user logs in the login program gets executed, the user gets
prompted twice for their password, they get an AFS token. The wtmp/utmp
files are not updated and I cannot tell who is logged in or has been
logged in.

I think it is up to the SGI login program to update these files at this
point, not the sshd daemon. If I do not use the UseLogin option the
sshd daemon updated the wtmp/utmp files just fine, (but I do not get an
AFS token).

I can call the /usr/bin/login program once I am logged into a session
that
uses the UseLogin option and the wtmp/utmp files still do not get
updated!

But if I call /usr/bin/login from the command line while logged into a
sshd session that does NOT use UseLogin the wtmp/utmp files do get
updated.

This leads me to believe when the login program is execl'ed it inherits
the sshd environment variables and there is something that the
/usr/bin/login program detects that causes it not to update wtmp/umtp?

I tried to prove this by using the execle() call instead of execl().
The execle() call allows you to pass a new environment in an array. I
set the environment array to contain just one variable. I was able to
login but this did not fix the problem!

I searched SGI's support for any updates to the /usr/bin/login program
and couldnot find anything. Note that on SGI the /usr/bin/login program
is a link to /usr/lib/iaf/scheme. I placed this program directly in the
execl call, execl("/usr/lib/iaf/scheme",... and this did not help.

I also tried to enable-- and disable-- the following configure
options,(which I could not find any documentation on), and this did not
help:

--disable-utmp          disable use of utmp even if detected no
--disable-utmpx         disable use of utmpx even if detected no
--disable-wtmp          disable use of wtmp even if detected no
--disable-wtmpx         disable use of wtmpx even if detected no


Any ideas out there?

-- 
John W. Sopko Jr.               University of North Carolina
email: sopko at cs.unc.edu         Computer Science Dept., CB 3175
Phone: 919-962-1844             Sitterson Hall; Room 135
Fax:   919-962-1799             Chapel Hill, NC 27599-3175

In regard to: Irix UseLogin wtmp/utmp bug, John W. Sopko Jr. said (at...:
>I think it is up to the SGI login program to update these files at this
>point, not the sshd daemon. If I do not use the UseLogin option the
>sshd daemon updated the wtmp/utmp files just fine, (but I do not get an
>AFS token).
>
>I can call the /usr/bin/login program once I am logged into a session
>that
>uses the UseLogin option and the wtmp/utmp files still do not get
>updated!
>
>But if I call /usr/bin/login from the command line while logged into a
>sshd session that does NOT use UseLogin the wtmp/utmp files do get
>updated.
I agree that it should be up to the SGI login program to update the
requisite files, and the fact that it works differently if you invoke it
after your login shell starts with UseLogin set does suggest that sshd
might be doing something that's tripping up /usr/bin/login.

Two suggestions:

1) Temporarily set

	UseLogin /tmp/login-script.sh

and have the script run the `env' command and dump that to some file.
That will get you what env your "login" program is seeing.

2) After setting UseLogin back to

	UseLogin /usr/bin/login

Use SGI's truss-equivalent, par, to trace the system calls that login
is executing on your behalf.  That may help, or it might not.


The fact that you tried execle and a stripped environment and still didn't
get the utmp/wtmp accounting probably means its not environment related,
but trying #1 anyway might be useful.

If you solve the problem, be sure to summarize to the list -- it's an
interesting one.

Tim
-- 
Tim Mooney                              mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

I placed a Call to SGI about this bug, here is there response
and my response to there response.

-------- Original Message --------
Subject: Re: [Fwd: Regarding Case Number 2356416]
Date: Thu, 01 Aug 2002 09:10:46 -0400
From: "John W. Sopko Jr." <sopko at cs.unc.edu>
To: "Chris Duffy (Loose Cannon)" <cjd at sgi.com>
CC: riley at cs.unc.edu
References: <3D48044C.2BAB347B at cs.unc.edu>
<3D481900.62149C64 at cs.unc.edu> <3D492E39.5EF60CB7 at
americas.sgi.com>

Thanks for looking at this. I am not a full time C programmer
but a system admin. It just seems to me that calling the
login/scheme program with a user name that program should do
all the work, the man page says, "After a successful login,
accounting files are updated".

I guess from your findings the parent process that calls
login/scheme is supposed to set this up which means it should
actually place a user entry in the utmp/wtmp files and then the
login/scheme program touches this up with some other info. 

I cannot spend time on this. Someone at OpenSSH would
need to know what the SGI login program expects and I would
guess they would need documentation and source code on the SGI
login/schem program so they can figure out how sshd and
login/scheme are to interact to update the accounting files.


"Chris Duffy (Loose Cannon)" wrote:
> 
> "John W. Sopko Jr." wrote:
> >
> > Note we upgraded one of our machines to Irix 6.5.16 and
> > this did not fix the problem.
> 
> Ok, I am done with my testing, etc.  What I found is the following
> and I will be writing a bug report on sshd and I guess it
> gets forwarded back to the openssh people (external to us)
> to get fixed.
> 
> -It does not matter what environment variables are set
> and passed to login/scheme.  With the "UseLogin" feature
> turned on, sshd does indeed create a different subset
> of environment variables but login/scheme on Irix does
> not care.  I changed the code in session.c to add all the
> same environment variables in all cases but it did not help.
> 
> -However, sshd via session.c and loginrec.c do all the login
> prep work as well are responsible to update the utmp/utmpx
> accounting files.  Based on what sshd writes into the
> utmp/utmpx records, Irix's login/scheme code will
> update it with some other info.  However, since the
> records were not updated properly by sshd, login/scheme
> basically ignores updating the records.  I'll explain why
> below.
> 
> -in the utmp/utmpx records, there is field, ut_type
> that records what state the record/user is in, i.e.
> 
> #define EMPTY           0
> #define RUN_LVL         1
> #define BOOT_TIME       2
> #define OLD_TIME        3
> #define NEW_TIME        4
> #define INIT_PROCESS    5       /* Process spawned by "init" */
> #define LOGIN_PROCESS   6       /* A "getty" process waiting for
login
> */
> #define USER_PROCESS    7       /* A user process */
> #define DEAD_PROCESS    8
> #define ACCOUNTING      9
> 
> sshd is supposed to put the records, both utmp and utmpx,
> into the USER_PROCESS state.  In the case where you do not use the
> "UseLogin yes", only one login/passwd is issued, it works
properly,
> i.e. sshd places the record(s) into USER_PROCESS state and
> login/scheme sees that they are valid and updates the record(s).
> Utilities like who/finger/last work properly.
> In the case where you do use "UseLogin yes", which causes
> sshd to login twice, session.c uses different logic where
> it does not call the proper routines in loginrec.c to
> update the utmp/utmpx records with the proper state, i.e.
> it does not update the records to USER_PROCESS state.
> In fact, it does not touch this field, i.e. they are 0
> or maybe set to DEAD_PROCESS but for sure it does not set
> the field to USER_PROCESS.
> 
> Now when Irix's login/scheme sees these records and does not
> find the state to be either USER_PROCESS or INIT_PROCESS,
> it does not update some of the other fields.....but no big deal.
> The utilities like who/finger/last only look at ut_type to see
> if the user is active but if they do not see USER_PROCESS or
> INIT_PROCESS, then they will ignore the entrys.
> 
> I also looked at some of the comments by others who modified
> sshd code and it looks like a few changes were made earlier
> in the year regarding this process.  Someone may have put
> code in to fix one problem and may have caused this one.
> The only thing I can do is get this info to our people who
> will get it back to openssh folks.
> 
> So for now, it is broken.  If you have the time to do more research
> you may be able to get it to work.....else ask someone else
> that contributes to the openssh project and they may come up with a fix.
> 
> If this is all, I will be closing this case, writing the
> bug report for our people.
> 
> Let me know.
> 
> Regards,
> Chris Duffy
> cjd at sgi.com
> 
> >
> > > FR: cjd
> > >
> > > Duncan,
> > >
> > > I have your case on login/sshd/wtmp problem.
> > > I am working with it at the moment and will get back to
> > > you with what I find.
> > >
> > > Regards,
> > > Chris Duffy
> > > cjd at sgi.com
> >
> > --
> > John W. Sopko Jr.               University of North Carolina
> > email: sopko at cs.unc.edu         Computer Science Dept., CB 3175
> > Phone: 919-962-1844             Sitterson Hall; Room 135
> > Fax:   919-962-1799             Chapel Hill, NC 27599-3175
> 
> --
> Regards, Chris Duffy
> 
>  _                            ____
> | |    ___   ___  ___  ___   / ___|__ _ _ __  _ __   ___  _ __
> | |   / _ \ / _ \/ __|/ _ \ | |   / _` | '_ \| '_ \ / _ \| '_ \
> | |__| (_) | (_) \__ \  __/ | |__| (_| | | | | | | | (_) | | | |
> |_____\___/ \___/|___/\___|  \____\__,_|_| |_|_| |_|\___/|_| |_|
> 
> +------------------------------+-------------------------------+
> | Chris Duffy - Network Support| Email: cjd at sgi.com            |
> | SGI Technology Solutions     | Fax:      (651) 683-5889      |
> | SGI                          | Voice:    (651) 683-5379      |
> | 655F Lone Oak Drive, MC 32   | Cell Phone: (612) 325-5831    |
> | Eagan, MN 55121-1560         | Pgr: 6123255831 at mobile.att.net|
> +------------------------------+-------------------------------+
-- 
John W. Sopko Jr.               University of North Carolina
email: sopko at cs.unc.edu         Computer Science Dept., CB 3175
Phone: 919-962-1844             Sitterson Hall; Room 135
Fax:   919-962-1799             Chapel Hill, NC 27599-3175