Bug 1296233 - login(1) writes 0.0.0.0 IP address to wtmp when executed with "-h <ipv4-mapping-to-ipv6>" hostname
login(1) writes 0.0.0.0 IP address to wtmp when executed with "-h <ipv4-mappi...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: util-linux (Show other bugs)
7.2
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Karel Zak
Radka Skvarilova
:
Depends On:
Blocks: 1298243 1420851 1465901
  Show dependency treegraph
 
Reported: 2016-01-06 11:27 EST by giulioo
Modified: 2018-04-10 13:26 EDT (History)
7 users (show)

See Also:
Fixed In Version: util-linux-2.23.2-44.el7
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-04-10 13:25:50 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test program (1.53 KB, text/x-csrc)
2017-07-03 07:07 EDT, Karel Zak
no flags Details
Strace output for getaddreinfo and ping (3.46 KB, text/plain)
2017-07-03 14:30 EDT, giulioo
no flags Details
Strace for ping (11.87 KB, text/plain)
2017-07-03 14:32 EDT, giulioo
no flags Details
improved test program (2.01 KB, text/x-csrc)
2017-07-04 06:09 EDT, Karel Zak
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0936 None None None 2018-04-10 13:26 EDT

  None (edit)
Description giulioo 2016-01-06 11:27:59 EST
Description of problem:
Wrong IP address of client session can be seen in the output of "last -i"

Version-Release number of selected component (if applicable):
telnet-server-0.17-59.el7.x86_64

How reproducible:
Always.

Note: I'm always using IPv4 addresses for client and server, the server has default link-local IPv6 but I don't use it.

=============================== Example
Host is RHEL72
pts/0 is telnet from another RHEL72 (192.168.1.126)
pts/1 is rlogin from another RHEL72 (192.168.1.126)
 
$ w
 16:21:00 up  7:16,  2 users,  load average: 0.01, 0.03, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
user1    pts/0    ::ffff:192.168.1 16:16   44.00s  0.01s  0.01s -bash
user1    pts/1    192.168.1.126    16:17    4.00s  0.06s  0.01s w
$ who
user1    pts/0        2016-01-06 16:16 (::ffff:192.168.1.126)
user1    pts/1        2016-01-06 16:17 (192.168.1.126)
$ last -n 2
user1    pts/1        192.168.1.126    Wed Jan  6 16:17   still logged in
user1    pts/0        ::ffff:192.168.1 Wed Jan  6 16:16   still logged in
 
wtmp begins Wed Jan  6 13:54:49 2016
$ last -n 2 -w
user1    pts/1        192.168.1.126    Wed Jan  6 16:17   still logged in
user1    pts/0        ::ffff:192.168.1.126 Wed Jan  6 16:16   still logged in
 
wtmp begins Wed Jan  6 13:54:49 2016
$ last -n 2 -w -i     [ * ERROR: 192.168.1.8 instead of real IP *]
user1    pts/1        192.168.1.126    Wed Jan  6 16:17   still logged in
user1    pts/0        192.168.1.8      Wed Jan  6 16:16   still logged in
 
wtmp begins Wed Jan  6 13:54:49 2016
 
ERROR:
- the pts/0 row, 3rd field of "last -w -i" output shows 192.168.1.8 instead of
  192.168.1.126 (or ::ffff:192.168.1.126)
- 192.168.1.8 is the IP of another client I was doing telnet tests with a few
  moments earlier
- It seems the wrong IP is being written to wtmp/utmp
 
================ I truncate  utmp files
# > /var/run/utmp
# > /var/log/wtmp
 
I then login again just via telnet
 
$ w
 16:27:32 up  7:22,  1 user,  load average: 0.12, 0.06, 0.05
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
user1    pts/0    ::ffff:192.168.1 16:27    3.00s  0.02s  0.02s w
$ who
user1    pts/0        2016-01-06 16:27 (::ffff:192.168.1.126)
$ last  -w
user1    pts/0        ::ffff:192.168.1.126 Wed Jan  6 16:27   still logged in
user1    tty1                          Wed Jan  6 16:27 - 16:27  (00:00)
 
wtmp begins Wed Jan  6 16:27:18 2016
$ last  -w -i
user1    pts/0        0.0.0.0          Wed Jan  6 16:27   still logged in
user1    tty1         0.0.0.0          Wed Jan  6 16:27 - 16:27  (00:00)
 
wtmp begins Wed Jan  6 16:27:18 2016
ERROR:
- the pts/0 row, 3rd field of "last -w -i" output shows 0.0.0.0 instead of
  192.168.1.126 (or ::ffff:192.168.1.126)
- 0.0.0.0 is the same IP logged for the console login I used to truncate the
  utmp/wtmp files
- Again, it seems old IPs are logged in utmp/wtmp of new sessions
 
 
=============================================================================
I see 2 issues:

1) telnet server appears to put wrong data (from an old session) in the
   utmp/wtmp field containing the IP address; maybe a variable doesn't get
   properly reset or something.
   The client always connect to the IPv4 address of the server; the server
   only has default "link-local" IPv6. If I disable IPv6 (either in linux
   cmdline or at telnet level with telnet.socket ListenStream override)
   the problem disappears.

2) cosmetic: I think telnet, when handling IPv4 clients, should use the IPv4  
   address x.x.x.x and not the ::ffff:x.x.x.x address as the hostname in
   utmp/wtmp (when it can't resolve then hostname to an IP), like rlogin
   already does.
   This way it won't get truncated in the "w" or "last" (w/o -w) outputs.
Comment 5 Karel Zak 2016-05-12 08:33:29 EDT
It would be better to use utmpdump rather than last(1) to be sure we really debug login(1) issue rather than any problem in last(1)..

And I have doubts that

  user1    pts/0        ::ffff:192.168.1.126 Wed Jan  6 16:16   still logged in

vs.

  user1    pts/0        192.168.1.8      Wed Jan  6 16:16   still logged in

is logging problem. It seems that last -i resolves the address and it gets another IP.
Comment 6 giulioo 2016-05-12 11:59:56 EDT
I couldn't quickly reproduce the wrong ip, but the 0.0.0.0 in place of the actual IP is in utmp. 

pts/0 is ssh
pts/1 is telnet
pts/2 is rlogin


==== While logged in
Utmp dump of /var/run/utmp
[6] [03903] [tty1] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Thu May 12 17:49:34 2016    ]
[7] [03906] [ts/0] [user1   ] [pts/0       ] [192.168.1.7         ] [192.168.1.7    ] [Thu May 12 17:49:39 2016    ]
[7] [03926] [1   ] [user1   ] [pts/1       ] [::ffff:192.168.1.7  ] [0.0.0.0        ] [Thu May 12 17:49:50 2016    ]
[7] [03950] [2   ] [user1   ] [pts/2       ] [192.168.1.7         ] [192.168.1.7    ] [Thu May 12 17:50:19 2016    ]

==== After logout
Utmp dump of /var/run/utmp
[7] [03903] [tty1] [user1   ] [tty1        ] [                    ] [0.0.0.0        ] [Thu May 12 17:55:14 2016    ]
[8] [03906] [ts/0] [        ] [pts/0       ] [                    ] [192.168.1.7    ] [Thu May 12 17:54:39 2016    ]
[8] [03926] [1   ] [        ] [pts/1       ] [                    ] [0.0.0.0        ] [Thu May 12 17:55:05 2016    ]
[8] [03950] [2   ] [        ] [pts/2       ] [                    ] [192.168.1.7    ] [Thu May 12 17:55:09 2016    ]

I would expect for telnet to put in utmp the same info as ssh/rlogin
Comment 22 Karel Zak 2017-07-03 07:07 EDT
Created attachment 1293831 [details]
test program

I have prepared simple test program for customer where is exactly the same code as we use in login(1) and utmpdump(1). It would be nice to try it.

* save attachment to getaddreinfo.c
* compile:

$ gcc -O2 -Wall    getaddreinfo.c   -o getaddreinfo

* try it with address used by telnetd:

$ ./getaddreinfo "::ffff:192.168.1.7"
name: ::ffff:192.168.1.7
addr: 192.168.1.7
Comment 23 giulioo 2017-07-03 14:30 EDT
Created attachment 1293936 [details]
Strace output for getaddreinfo and ping
Comment 24 giulioo 2017-07-03 14:31:53 EDT
$ /tmp/getaddreinfo ::ffff:192.168.1.126
name: ::ffff:192.168.1.126
addr: 0.0.0.0
$
 
$ last -w
user1    pts/1        ::ffff:192.168.1.126 Mon Jul  3 20:15   still logged in
user1    pts/0        ::ffff:192.168.1.126 Mon Jul  3 19:54   still logged in
user1    tty1                          Mon Jul  3 19:54 - 19:54  (00:00)
 
wtmp begins Mon Jul  3 19:54:34 2017
$ last -w  -i
user1    pts/1        0.0.0.0          Mon Jul  3 20:15   still logged in
user1    pts/0        0.0.0.0          Mon Jul  3 19:54   still logged in
user1    tty1         0.0.0.0          Mon Jul  3 19:54 - 19:54  (00:00)
 
wtmp begins Mon Jul  3 19:54:34 2017
 
======================================================
What component/library/rpm is supposed to translate ::ffff:192.168.1.126 as a "n
ame" into 192.168.1.126?
Maybe it's not installed on my system?
 
==== ping manages to do it:
$ ping -c 1 ::ffff:192.168.1.126
PING ::ffff:192.168.1.126 (192.168.1.126) 56(84) bytes of data.
64 bytes from 192.168.1.126 (192.168.1.126): icmp_seq=1 ttl=64 time=12.1 ms
=====
 
I'm attaching strace's output for getaddreinfo and for ping
Comment 25 giulioo 2017-07-03 14:32 EDT
Created attachment 1293938 [details]
Strace for ping
Comment 26 Karel Zak 2017-07-04 06:06:13 EDT
Thanks giulioo. It works on my Fedora, but not on RHEL.

I thought it's about system configuration, but it's probably bad direction to blame configuration, package versions or order of addresses with in the getaddrinfo() result.

The code in login(1) has to robust to be usable everywhere.

I'll improve login(1) to detect IPV4-mapping-to-IPV6 and use IPV4 in the log files.

It's too late for RHEL7.4, so I guess it will be fixed in RHEL7.5. 

Thanks for debugging and patience!
Comment 27 Karel Zak 2017-07-04 06:09 EDT
Created attachment 1294152 [details]
improved test program

Now the test program supports IPV4-mapping to IPV6.

on RHEL7:

$ gcc -O2 -Wall    getaddreinfo.c   -o getaddreinfo

$ ./getaddreinfo  ::ffff:10.10.161.32
remapping to IPV4
name: ::ffff:10.10.161.32
addr: 10.10.161.32
Comment 28 Karel Zak 2017-07-04 07:05:40 EDT
Fixed by upstream commit 1c8792f1ae7fa38cf1d4418ad99c207f65dfdb1a.
Comment 29 giulioo 2017-07-04 15:28:18 EDT
This works for me too.

$ /tmp/getaddreinfo2 ::ffff:192.168.1.126
remapping to IPV4
name: ::ffff:192.168.1.126
addr: 192.168.1.126
$

Thanks
Comment 35 Radka Skvarilova 2018-02-15 06:57:18 EST
Hi,
could you please help us with verification?
I can just do the sanity testing, but I would be glad if you confirm the fix
Comment 36 giulioo 2018-02-20 10:02:21 EST
Locally, I applied this patch

https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/patch/?id=1c8792f1ae7fa38cf1d4418ad99c207f65dfdb1a

to

util-linux-2.23.2-43.el7.src.rpm

and rebuilt "/bin/login", and issue is corrected.

If this is what you were asking.
Comment 40 errata-xmlrpc 2018-04-10 13:25:50 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0936

Note You need to log in before you can comment on or make changes to this bug.