Red Hat Bugzilla – Bug 1296233
login(1) writes 0.0.0.0 IP address to wtmp when executed with "-h <ipv4-mapping-to-ipv6>" hostname
Last modified: 2018-04-10 13:26:58 EDT
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.
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.
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
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
Created attachment 1293936 [details] Strace output for getaddreinfo and ping
$ /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
Created attachment 1293938 [details] Strace for ping
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!
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
Fixed by upstream commit 1c8792f1ae7fa38cf1d4418ad99c207f65dfdb1a.
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
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
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.
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