Irix UseLogin wtmp/utmp bug
John W. Sopko Jr.
sopko at cs.unc.edu
Thu Aug 1 23:20:16 EST 2002
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
More information about the openssh-unix-dev
mailing list