News Group Posts

sshd stty login

From: Bela Lubkin <belal@sco.com>
Subject: Re: sco-list: [OFF] OpenSSH on OpenServer 5.0.6a
Date: Wed, 1 May 2002 22:16:45 GMT
References: <20020430191159.I10046@mammoth.ca.sco.com>
<20020501023509.GD26641@jpradley.jpr.com>
<20020501012942.L10046@mammoth.ca.sco.com>
<20020501210650.GE17632@jpradley.jpr.com> 

Jean-Pierre Radley wrote:

> | So recompile sshd to either leave out the "-h remhost" part, or change
> | it to "-r remhost //sshd//"; see how it goes.
> 
> Neither choice works. They both lead to
>    No utmp entry. You must exec "LOGIN" from the lowest level "sh".

Like I said, this used to work with some older version of OpenSSH.  They
changed what they expected login to do and didn't check that the results
worked with all the OSes OpenSSH can be built for.

"No utmp entry" means no utmp entry.  See if there's code nearby, maybe
ifdef'd or runtime-configured out, that establishes a utmp entry for the
session it's trying to start.

> The rest of the options used by ssh don't seem to jibe with OSR's
> /bin/login either:
> 
>    if (options.use_login) {
>                 /* Launch login(1). */
>                 execl(LOGIN_PROGRAM, "login", "-h", hostname,
>    #ifdef LOGIN_NEEDS_TERM
>                     (s->term ? s->term : "unknown"),
>    #endif /* LOGIN_NEEDS_TERM */
>                     "-p", "-c", "-f", "--", pw->pw_name, (char *)NULL);
> 
> I tried removing the "-p" and the "--" ; neither helped.

Ah, they're using "-f", so my advice about working around .rhosts issues
is probably irrelevant.  Use "-r remhost remuser", i.e. supplying the
true names of both, if they are known.

OSR5 login supports "-p" and (since it uses getopt()) won't be thrown by
"--".

> As for luid, I see code that reads:
>    # if defined(HAVE_GETLUID) && defined(HAVE_SETLUID)
>                    /* Sets login uid for accounting */
>                    if (getluid() == -1 && setluid(pw->pw_uid) == -1)
>                            error("setluid: %s", strerror(errno));
>    # endif /* defined(HAVE_GETLUID) && defined(HAVE_SETLUID) */
> 
> 'Configure' did define both HAVE_GETLUID and HAVE_SETLUID to 1.

Then getluid() isn't returning -1.  That means that sshd is running with
an LUID.  How is it started -- by inetd?  Then inetd must be running
with an LUID, and that's bad...

To check the LUID of a live process:

  # ps -fp1,1309
       UID   PID  PPID  C    STIME     TTY        TIME CMD
      root     1     0  0   Apr-24       ?    00:00:07 /etc/init
     belal  1309  1308  0   Apr-25   ttyp0    00:00:01 -ksh
  # crash
  > p #1 #1309
   PROC TABLE SIZE = 130
   SLOT ST  PID  PPID  PGRP   UID PRI CPU EVENT            NAME           FLAGS
      1 s     1     0     0     0  66   0 u                init           load
     74 s  1309  1308  1309 12039  73   0 proc+0x6370      ksh            load ntrc
     ^^ SLOT NUMBER -- convert to hex == 1, 4A
  > quit
  # scodb
  scodb> secinfo[1].si_luid_set
  0                                <-- process's LUID is not set
  scodb> secinfo[4A].si_luid_set
  1                                <-- process's LUID is set
  scodb> secinfo[4A].si_luid
  2F07                             <-- process's LUID is 0x2F07 = 12039
  scodb> quit

>Bela<
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.