[Toybox] [PATCH] telnetd: pass `-h hostname` to login(1).

[enh]

On Sat, Apr 24, 2021 at 2:30 AM Rob Landley <rob at landley.net> wrote:

> On 4/22/21 9:00 PM, enh via Toybox wrote:
> > Handling utmp is login's job: telnetd should just pass the appropriate
> > option to login.
>
> Introducing a call to getnameinfo... you're doing a DNS lookup on yourself?
>

it's early on Monday morning, so i may have missed something but...

the call to getpeername(2) is the interesting bit:

  if (getpeername(sockfd, (void *)&sa, &sl)) perror_exit("getpeername");
  if (getnameinfo((void *)&sa, sl, toybuf, sizeof(toybuf), NULL, 0, 0))

we're asking for the name of the *other end* of the socket.

(Given that telnet isn't encrypted, I'd expect most of the calls to take
> place
> in a LAN environment possibly with no gateway?)
>
> Is this going to produce a different result from gethostname()?
>
> > (I was investigating a different bug that caused telnetd to take 100%
> > CPU after a network outage and noticed an unexpected utmp fd. It turned
> > out to not be relevant to my actual problem, but it did remind me that
> > this utmp code isn't right in small details like that, but also in the
> > bigger picture: it's writing the wrong information, and only on logout,
> > not login. But rather than try to fix it, let's just let login do its
> > job.)
>
> I'm all for ripping out the utmp plumbing here, I'm just confused about
> where
> this data is coming from what what it's used for...
>

i could barely remember myself because it's been >20 years, but commands
like who(1) show who's logged on and "from where". my understanding is that
it's supposed to be the job of login(1) to write the login and logout
records that are used for this. for some reason telnetd was trying to do it
itself (but was only writing one of the records anyway, and even that not
correctly).

so, yeah, i don't think anyone needs this in 2021 -- and sincerely doubt
that anyone's going to run telnetd except to test telnet -- but that seemed
all the more reason to reduce the amount of code we're carrying around here
:-)


> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210426/8616cccd/attachment.htm>