From kirk@kanga.honeypot.net  Mon Sep 22 07:50:13 2003
Return-Path: <kirk@kanga.honeypot.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id E9BCE16A4B3
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 22 Sep 2003 07:50:13 -0700 (PDT)
Received: from kanga.honeypot.net (kanga.honeypot.net [208.162.254.122])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 7D7B344001
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 22 Sep 2003 07:50:09 -0700 (PDT)
	(envelope-from kirk@kanga.honeypot.net)
Received: from kanga.honeypot.net (localhost [127.0.0.1])
	by kanga.honeypot.net (8.12.9/8.12.9) with ESMTP id h8MEo1NS056130
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 22 Sep 2003 09:50:05 -0500 (CDT)
	(envelope-from kirk@kanga.honeypot.net)
Received: (from root@localhost)
	by kanga.honeypot.net (8.12.9/8.12.9/Submit) id h8MEo197056129;
	Mon, 22 Sep 2003 09:50:01 -0500 (CDT)
	(envelope-from kirk)
Message-Id: <200309221450.h8MEo197056129@kanga.honeypot.net>
Date: Mon, 22 Sep 2003 09:50:01 -0500 (CDT)
From: Kirk Strauser <kirk@strauser.com>
Reply-To: Kirk Strauser <kirk@strauser.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: "w" does not honor the -n option
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         57089
>Category:       bin
>Synopsis:       w(1) does not honor the -n option
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pluknet
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Sep 22 08:00:28 PDT 2003
>Closed-Date:    Sat Nov 13 15:38:14 UTC 2010
>Last-Modified:  Sat Nov 13 15:40:38 UTC 2010
>Originator:     Kirk Strauser <kirk@strauser.com>
>Release:        FreeBSD 5.1-CURRENT i386
>Organization:
The Strauser Group
>Environment:
System: FreeBSD kanga.honeypot.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Fri Sep 19 14:51:41 CDT 2003 root@kanga.honeypot.net:/usr/obj/usr/src/sys/KANGA i386


	
>Description:
w's -n option is supposed to prevent resolution of the network addresses
that users are connecting from.  On my 5.1-CURRENT system, built on
2003-09-19, this is not the case.

w's normal output:

    kirk@kanga:~$ w
     9:29AM  up 2 days, 17:04, 2 users, load averages: 0.42, 0.61, 0.68
    USER             TTY      FROM              LOGIN@  IDLE WHAT
    kirk             p0       pooh              9:22AM     - w
    kirk             p1       pooh              9:23AM     - vim /tmp/pf.eAAIb48f

With the -n option to prevent address resolution:

    kirk@kanga:~$ w -n
     9:29AM  up 2 days, 17:04, 2 users, load averages: 0.42, 0.61, 0.68
    USER             TTY      FROM              LOGIN@  IDLE WHAT
    kirk             p0       pooh              9:22AM     - w -n
    kirk             p1       pooh              9:23AM     - vim /tmp/pf.eAAIb48f

	
>How-To-Repeat:
The problem is trivially repeatable; just re-run "w -n".
	
>Fix:
I don't have a lot of experience with wtmp, but it looks like the default
value for the host field is set by these lines:

    strncpy(host_buf, ep->utmp.ut_host, UT_HOSTSIZE);
    p = *host_buf ? host_buf : "-";

If the "nflag" variable (set if "-n" is specified at the command line) is
true, then "p" is reset to the value of the resolved address.

However, it seems that the "ep->utmp.ut_host" field is also a string
containing the resolved hostname; "p" is never assigned anything that looks
like a numeric IP.

	


>Release-Note:
>Audit-Trail:

From: Dima Dorfman <dima@trit.org>
To: Kirk Strauser <kirk@strauser.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Mon, 22 Sep 2003 21:54:10 +0000

 Kirk Strauser <kirk@strauser.com> wrote:
 > 
 > >Number:         57089
 > >Category:       bin
 > >Synopsis:       "w" does not honor the -n option
 > 	
 > >Description:
 > w's -n option is supposed to prevent resolution of the network addresses
 > that users are connecting from.  On my 5.1-CURRENT system, built on
 > 2003-09-19, this is not the case.
 
 I think the "-n" option is intended to prevent name resolution to
 avoid a display delay--not necessarily to display numeric addresses
 (name resolution can be slow, possibly requiring dialing out the
 Internet, and so on, so it's useful to be able to tell w(1) not to do
 it).  If utmp already has a name, it can be displayed without
 incurring any lookup delay, so w(1) does so.
 
 Hope this helps,
 
 Dima.

From: Kirk Strauser <kirk@strauser.com>
To: Dima Dorfman <dima@trit.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Mon, 22 Sep 2003 17:07:46 -0500

 --=-=-=
 Content-Transfer-Encoding: quoted-printable
 
 At 2003-09-22T21:54:10Z, Dima Dorfman <dima@trit.org> writes:
 
 > I think the "-n" option is intended to prevent name resolution to avoid a
 > display delay--not necessarily to display numeric addresses (name
 > resolution can be slow, possibly requiring dialing out the Internet, and
 > so on, so it's useful to be able to tell w(1) not to do it).  If utmp
 > already has a name, it can be displayed without incurring any lookup
 > delay, so w(1) does so.
 
 
 However, that's different from the behavior in 4.x systems (at least, as of
 the 4.7 server that I have access to):
 
     kirk@glaaki:/usr/src/usr.bin/w$ w -n
      5:06PM  up 14 days,  8:36, 3 users, load averages: 0.09, 0.06, 0.01
     USER             TTY      FROM              LOGIN@  IDLE WHAT
     corwin           p0       12.218.138.143    1:09PM  1:10 psql template1
     corwin           p1       12.218.138.143   Sat09PM 21:47 -bash (bash)
     kirk             p2       208.162.254.126   4:59PM     - w -n
 
 I'd definitely think that's the more appropriate behavior, since it would be
 analogous to the "-n" (mnemmonic: "numeric") options of other utilities
 such as netstat.
 =2D-=20
 Kirk Strauser
 
 --=-=-=
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (GNU/Linux)
 
 iD8DBQA/b3LC5sRg+Y0CpvERArlDAKCStwI1iQKTYXF4r3YDU5BHP2bFCgCgluGL
 HINves+MPdz0+DWOd8Og+No=
 =L9sy
 -----END PGP SIGNATURE-----
 --=-=-=--
 

From: Dima Dorfman <dima@trit.org>
To: Kirk Strauser <kirk@strauser.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org, brian@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Mon, 22 Sep 2003 22:43:00 +0000

 Kirk Strauser <kirk@strauser.com> wrote:
 > At 2003-09-22T21:54:10Z, Dima Dorfman <dima@trit.org> writes:
 > 
 > > I think the "-n" option is intended to prevent name resolution to avoid a
 > > display delay--not necessarily to display numeric addresses (name
 > > resolution can be slow, possibly requiring dialing out the Internet, and
 > > so on, so it's useful to be able to tell w(1) not to do it).  If utmp
 > > already has a name, it can be displayed without incurring any lookup
 > > delay, so w(1) does so.
 > 
 > 
 > However, that's different from the behavior in 4.x systems (at least, as of
 > the 4.7 server that I have access to):
 > 
 >     kirk@glaaki:/usr/src/usr.bin/w$ w -n
 >      5:06PM  up 14 days,  8:36, 3 users, load averages: 0.09, 0.06, 0.01
 >     USER             TTY      FROM              LOGIN@  IDLE WHAT
 >     corwin           p0       12.218.138.143    1:09PM  1:10 psql template1
 >     corwin           p1       12.218.138.143   Sat09PM 21:47 -bash (bash)
 >     kirk             p2       208.162.254.126   4:59PM     - w -n
 > 
 > I'd definitely think that's the more appropriate behavior, since it would be
 > analogous to the "-n" (mnemmonic: "numeric") options of other utilities
 > such as netstat.
 
 It seems that you're right about the intention (I always thought -n
 was to avoid doing lookups, and I've always used it for that purpose).
 
 The behavior was changed in this commit of w.c:
 
 ----------------------------
 revision 1.48
 date: 2001/07/26 19:20:13;  author: brian;  state: Exp;  lines: +40 -41
 When -n is specified, don't attempt to turn hostnames found in utmp
 into addresses as we have no idea what address family they belong to.
 
 When -n is not specified, resolve IPv6 as well as IPv4 addresses found
 in the host field of utmp.  Use realhostname_sa() to resolve addresses
 (the old code was wrong).
 ...
 
 and it looks like that rationale still applies.  I've cc'd brian (who
 made that change) to see whether he has any input on this.  The issue
 is: So, you want to see numeric addresses--but for which family?  If a
 host resolves to a v4 and v6 address, which one should be displayed?
 Perhaps the programs that write to utmp/wtmp should just avoid writing
 hostnames? (although this is just a thought--I haven't tried to think
 through the implications of doing something like that)
 
 Dima.

From: Kirk Strauser <kirk@strauser.com>
To: Dima Dorfman <dima@trit.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, brian@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Mon, 22 Sep 2003 18:39:18 -0500

 --=-=-=
 Content-Transfer-Encoding: quoted-printable
 
 At 2003-09-22T22:43:00Z, Dima Dorfman <dima@trit.org> writes:
 
 > and it looks like that rationale still applies.
 
 That makes a certain kind of sense, I suppose.
 
 > I've cc'd brian (who made that change) to see whether he has any input on
 > this.  The issue is: So, you want to see numeric addresses--but for which
 > family?  If a host resolves to a v4 and v6 address, which one should be
 > displayed?
 
 Ideally, you'd see the address of the socket that the user is connecting on.
 For diagnostic purposes, it'd be nice to get a deterministic answer that tty
 p0 is connecting from 10.0.5.128, and tty p1 is connecting from
 2001:470:1f00:546:2a0:c9ff:fe08:260a .
 
 > Perhaps the programs that write to utmp/wtmp should just avoid writing
 > hostnames?  (although this is just a thought--I haven't tried to think
 > through the implications of doing something like that)
 
 Well, I could see that it may be useful to have a "snapshot" of what the
 hostname was at the time the user originally connected - DNS records do
 change, after all - but is there a good reason not to additionally store the
 address?
 =2D-=20
 Kirk Strauser
 
 --=-=-=
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (GNU/Linux)
 
 iD8DBQA/b4gr5sRg+Y0CpvERAhi5AJ97VGd1BTc0yUIEsGr0u+AfwDy7/wCfSwQ4
 20Qcqpwvs9+UeGdiKqyLaE8=
 =CmFG
 -----END PGP SIGNATURE-----
 --=-=-=--
 

From: Kirk Strauser <kirk@strauser.com>
To: "Matthew D. Fuller" <fullermd@over-yonder.net>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Wed, 24 Sep 2003 08:53:02 -0500

 --=-=-=
 Content-Transfer-Encoding: quoted-printable
 
 At 2003-09-24T06:18:35Z, "Matthew D. Fuller" <fullermd@over-yonder.net> wri=
 tes:
 
 >> but is there a good reason not to additionally store the address?
 
 > See utmp(5):
 
 > I believe the format of the structure is also constrained in some way by
 > POSIX, so we may not, even if we wanted to, be able to add arbitrary
 > fields.
 
 Ahhh - that was the part I was wondering about.  It seemed straightforward
 to add to the struct, but I admittedly know nothing about the standards
 involved.
 
 > Personally, I tend to think that storing both the PTR resolution and the
 > address would be a good thing, but when constrained to one the address is
 > DEFINITELY the one we want to keep in preference to a possibly transient
 > name.
 
 I agree completely.  There may be a large number of addresses with the same
 hostname, but the address is (hopefully) a unique identifier.
 =2D-=20
 Kirk Strauser
 
 --=-=-=
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.3 (GNU/Linux)
 
 iD8DBQA/caHO5sRg+Y0CpvERAuSuAJ4qtCfHTQJeqi7T4pZKbNMu+obXnQCZAbWr
 eZ7Qy7SIYiqpYG35zyk463U=
 =1lCv
 -----END PGP SIGNATURE-----
 --=-=-=--
 

From: Brian Somers <brian@Awfulhak.org>
To: Kirk Strauser <kirk@strauser.com>
Cc: Dima Dorfman <dima@trit.org>, FreeBSD-gnats-submit@FreeBSD.org,
	brian@FreeBSD.org
Subject: Re: bin/57089: "w" does not honor the -n option
Date: Sun, 28 Sep 2003 18:37:41 +0100

 I think this conversation reduces to the requirement for a new utmp format.
 And if we're going that route, we should really look at utmpx.  I don't think
 anyone's done more than look at it though :*/
 
 On Mon, 22 Sep 2003 18:39:18 -0500, Kirk Strauser <kirk@strauser.com> wrote:
 > At 2003-09-22T22:43:00Z, Dima Dorfman <dima@trit.org> writes:
 > 
 > > and it looks like that rationale still applies.
 > 
 > That makes a certain kind of sense, I suppose.
 > 
 > > I've cc'd brian (who made that change) to see whether he has any input on
 > > this.  The issue is: So, you want to see numeric addresses--but for which
 > > family?  If a host resolves to a v4 and v6 address, which one should be
 > > displayed?
 > 
 > Ideally, you'd see the address of the socket that the user is connecting on.
 > For diagnostic purposes, it'd be nice to get a deterministic answer that tty
 > p0 is connecting from 10.0.5.128, and tty p1 is connecting from
 > 2001:470:1f00:546:2a0:c9ff:fe08:260a .
 > 
 > > Perhaps the programs that write to utmp/wtmp should just avoid writing
 > > hostnames?  (although this is just a thought--I haven't tried to think
 > > through the implications of doing something like that)
 > 
 > Well, I could see that it may be useful to have a "snapshot" of what the
 > hostname was at the time the user originally connected - DNS records do
 > change, after all - but is there a good reason not to additionally store the
 > address?
 > -- 
 > Kirk Strauser
 > 
 
 
 -- 
 Brian <brian@Awfulhak.org>                        <brian@[uk.]FreeBSD.org>
       <http://www.Awfulhak.org>                   <brian@[uk.]OpenBSD.org>
 Don't _EVER_ lose your sense of humour !
State-Changed-From-To: open->closed 
State-Changed-By: pluknet 
State-Changed-When: Sat Nov 13 15:24:07 UTC 2010 
State-Changed-Why:  
Fixed in r199655 in 9-CURRENT. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=57089 
Responsible-Changed-From-To: freebsd-bugs->pluknet 
Responsible-Changed-By: pluknet 
Responsible-Changed-When: Sat Nov 13 15:40:05 UTC 2010 
Responsible-Changed-Why:  
Track (just in case). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=57089 
>Unformatted:
