| Summary: | login(1) writes 0.0.0.0 IP address to wtmp when executed with "-h <ipv4-mapping-to-ipv6>" hostname | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | giulioo | ||||||||||
| Component: | util-linux | Assignee: | Karel Zak <kzak> | ||||||||||
| Status: | CLOSED ERRATA | QA Contact: | Radka Brychtova <rskvaril> | ||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||
| Priority: | unspecified | ||||||||||||
| Version: | 7.2 | CC: | csong, giulioo, kzak, mpoole, rskvaril, thozza, zdohnal | ||||||||||
| Target Milestone: | rc | ||||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | Unspecified | ||||||||||||
| OS: | Unspecified | ||||||||||||
| Whiteboard: | |||||||||||||
| 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 17:25:50 UTC | Type: | Bug | ||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||
| Documentation: | --- | CRM: | |||||||||||
| Verified Versions: | Category: | --- | |||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
| Bug Depends On: | |||||||||||||
| Bug Blocks: | 1298243, 1420851, 1465901 | ||||||||||||
| Attachments: |
|
||||||||||||
|
Description
giulioo
2016-01-06 16:27:59 UTC
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 |