This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 521146 - who command always uses DNS to resolve login hosts
who command always uses DNS to resolve login hosts
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: coreutils (Show other bugs)
11
i686 Linux
low Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-03 17:04 EDT by Eric Varsanyi
Modified: 2009-09-04 08:25 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-03 18:45:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Eric Varsanyi 2009-09-03 17:04:44 EDT
The who utility has a documented flag (--lookup) that enables looking up hostnames in DNS corresponding to the IP address of the logged in user. The documentation indicates this is off by default, however it appears to be on by default.

There is no obvious way to turn it off if you want the documented behavior.


Version-Release number of selected component (if applicable):
coreutils-7.2-3.fc11.i586



How reproducible: consistently


Steps to Reproduce:
1. Log into a machine with ssh
2. type 'who' or 'who -m'
3. type 'who --lookup' or 'who -m --lookup'
  
Actual results:

[root@firedog shorewall]# who
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/1        2009-09-03 15:14 (68-29-93-120.pools.spcsdns.net)
ev       pts/2        2009-09-03 15:41 (srv.foo21.com)
[root@firedog shorewall]# who --lookup
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/1        2009-09-03 15:14 (68-29-93-120.pools.spcsdns.net)
ev       pts/2        2009-09-03 15:41 (srv.foo21.com)


Expected results:
Similar to above but with raw IP addresses rather than the reverse DNS name in the first invocation.


Additional info:
Comment 1 Kamil Dudka 2009-09-03 17:20:12 EDT
(In reply to comment #0)
> The who utility has a documented flag (--lookup) that enables looking up
> hostnames in DNS corresponding to the IP address of the logged in user. The
> documentation indicates this is off by default, however it appears to be on by
> default.

Why do you think it appears to be on?

Please attach the output of:
$ strings /var/run/utmp

Are you experiencing any significant delays?

If yes, then please attach output of:
$ strace -r who
Comment 2 Eric Varsanyi 2009-09-03 18:45:30 EDT
[root@firedog ~]# strings /var/run/utmp
reboot
2.6.29.6-217.2.16.fc11.i586
runlevel
2.6.29.6-217.2.16.fc11.i586
tty5
LOGIN
tty3
LOGIN
tty6
LOGIN
tty4
LOGIN
tty2
LOGIN
tty1
pts/0
:0.0
pts/1
ts/1root
68-29-93-120.pools.spcsdns.net
pts/2
ts/2ev
srv.foo21.com
pts/3
ts/3root
65.103.33.174
pts/4
ts/4root
65.103.33.174

So... I thought the IP was always logged in utmp and who was interpreting them, I guess its sshd that's resolving the IP and logging it there (and yes I get delays when DNS isn't working right for some reason, but they are during login as one would expect, not running who).

If I turn off the UseDNS option in sshd I do see IP's, though it appears --lookup doesn't resolve the ones that should be resolvable (which was not the topic of this bug, if its appropriate I will open another one if you like):

NEW firedog ~$ who
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/3        2009-09-03 16:25 (65.103.33.174)
ev       pts/4        2009-09-03 17:40 (192.172.252.16)
NEW firedog ~$ who --lookup
ev       tty1         2009-08-31 00:22 (:0)
ev       pts/0        2009-08-31 00:32 (:0.0)
root     pts/3        2009-09-03 16:25 (65.103.33.174)
ev       pts/4        2009-09-03 17:40 (192.172.252.16)
NEW firedog ~$ host 192.172.252.16
16.252.172.192.in-addr.arpa domain name pointer srv.foo21.com.


Apologies, I will close this as invalid and find an alternate way to get a list of raw IP's from which people are logged in on.

Thanks for your time!
Comment 3 Kamil Dudka 2009-09-04 03:30:57 EDT
Thanks for the analysis! As for the unresolved IPs, this seems like the relevant code, doing the canonicalization:

  static struct addrinfo hints;
  struct addrinfo *res = NULL;
  int status;

  hints.ai_flags = AI_CANONNAME;
  status = getaddrinfo (host, NULL, &hints, &res);

I'll check if it is bug or documented behavior. You don't need to open a separate ticket for now.
Comment 4 Kamil Dudka 2009-09-04 08:25:57 EDT
This also does not look like a coreutils bug. The 'who' utility attempts to canonicalize hostname as documented. However result is the same as input:

canon_host_r (host=0x7fffffffdb40 "10.34.33.205", cherror=0x60e500) at canon-host.c:69
69        hints.ai_flags = AI_CANONNAME;
(gdb) f
#0  canon_host_r (host=0x7fffffffdb40 "10.34.33.205", cherror=0x60e500) at canon-host.c:69
69        hints.ai_flags = AI_CANONNAME;
(gdb) n
70        status = getaddrinfo (host, NULL, &hints, &res);
(gdb)
71        if (!status)
(gdb) inf lo
retval = 0x0
hints = {
  ai_flags = 2,
  ai_family = 0,
  ai_socktype = 0,
  ai_protocol = 0,
  ai_addrlen = 0,
  ai_addr = 0x0,
  ai_canonname = 0x0,
  ai_next = 0x0
}
res = 0x6133f0
status = 0
(gdb) print *res
$2 = {
  ai_flags = 2,
  ai_family = 2,
  ai_socktype = 1,
  ai_protocol = 6,
  ai_addrlen = 16,
  ai_addr = 0x613420,
  ai_canonname = 0x6132e0 "10.34.33.205",
  ai_next = 0x613440
}

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