NetBSD Problem Report #6594

Received: (qmail 11509 invoked from network); 15 Dec 1998 20:54:42 -0000
Message-Id: <m0zq1Tt-0009N8C@most.weird.com>
Date: Tue, 15 Dec 1998 15:54:09 -0500 (EST)
From: woods@mail.weird.com
Reply-To: woods-netbsd@planix.com
To: gnats-bugs@gnats.netbsd.org
Subject: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
X-Send-Pr-Version: 3.95

>Number:         6594
>Category:       security
>Synopsis:       the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    security-officer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Dec 15 13:05:01 +0000 1998
>Closed-Date:    
>Last-Modified:  Sat Jan 19 23:05:03 +0000 2008
>Originator:     Greg A. Woods
>Release:        NetBSD-current
>Organization:
Planix, Inc.; Toronto, Ontario; Canada
>Environment:

	$NetBSD: mountd.c,v 1.51 1998/11/07 18:31:36 christos Exp $
	$NetBSD: exports.5,v 1.14 1998/10/07 14:52:30 christos Exp $
	master.passwd as of Mon Nov 16 08:02:37 EST 1998

>Description:

	I don't know if this is really a sw-bug or a doc-bug, but
	there's a misleading discrepancy in the default system
	configuration.  The correct category might be "bin", though
	since it has something to do with security and the default
	/etc/master.passwd I've initially submitted it as "security". 

	The default NFS mapping for the unprivileged account is to
	uid=-2, gid=-2 yet the default master.passwd file lists "nobody"
	as uid=32767, gid=9999".

	This is not critical since it only means remote NFS clients may
	have their root user accesses mapped to an ID that's not listed
	in the server's password file, but if anyone's expecting the
	default mapping to be to "nobody" they'll be misled until they
	realize that "nobody" isn't "-2:-2" as it always was on SunOS!  ;-)

>How-To-Repeat:

	see exports(5), src/usr.sbin/mountd/mountd.c, and src/etc/master.passwd

>Fix:

	either change mountd to use "32767:9999" as the default
	credentials, or change master.passwd to assign "-2:-2" as the
	user/group-id for "nobody".

	also add a comment to mountd.c and exports.5 to remind
	developers that tradition dictates that these credentials be
	assigned to the user "nobody".

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->security-officer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Thu Jan 14 01:04:30 PST 1999 
Responsible-Changed-Why:  
This PR is the responsibility of the NetBSD Security Officer, 
not the GNATS database administrator. 

From: "Erik E. Fair" <fair@digital.clock.org>
To: gnats-bugs@gnats.netbsd.org
Cc:  Subject: Re: security/6594
Date: Sat, 29 Jan 2000 21:23:36 -0800 (PST)

 Date:	Wed, 17 Nov 1999 12:38:27 -0800
 To:	tech-security@NetBSD.ORG
 From:	Erik Fair <security-officer@NetBSD.ORG>
 Subject: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID

 Greg Woods observes that our "nobody" doesn't match Sun's, or our
 own "mountd" value of (-2).

 Solaris:

 	nobody:x:60001:60001:Nobody:/:/sbin/noshell

 SunOS:

 	nobody:*:65534:65534:Mr. &:/:

 NetBSD:

 	nobody:*:32767:9999:Mr. &:/nonexistent:/sbin/nologin

 This is one of those consistency issues which pops up when NFS is used.

 Do we care enough to change it? Does NFS specify a UID value range
 (i.e. how many bits, and therefore is there an LP64 issue here)?

 What do the other UNIX-like OSes (e.g. System V, AIX, IRIX) do? (I
 don't have access to any of those these days, partly by choice).

 	seeking opinion, since I have none,

 	Erik <fair@clock.org>


 Date:	Thu, 18 Nov 1999 01:15:02 +0100 (MET)
 From:	Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>


 On Wed, 17 Nov 1999, Erik Fair wrote:
 | What do the other UNIX-like OSes (e.g. System V, AIX, IRIX) do? (I 
 | don't have access to any of those these days, partly by choice).

 miyu% ssh rfhsi8002 'uname -a ; grep nobody /etc/passwd /etc/group'
 IRIX rfhsi8002 6.2 03131015 IP22
 /etc/passwd:nobody:*:60001:60001:SVR4 nobody uid:/dev/null:/dev/null
 /etc/passwd:nobody:*:-2:-2:original nobody uid:/dev/null:/dev/null
 /etc/group:nobody:*:60001:

 | uname -a
 AIX rfhpa8001 1 4 00224F18E000
 | grep nobody /etc/passwd /etc/group
 /etc/passwd:nobody:!:4294967294:4294967294::/:
 /etc/group:nobody:!:4294967294:nobody,lpd


  - Hubert

 Date:	Thu, 18 Nov 1999 12:20:23 +0200
 From:	Antti Kantee <pooka@cs.hut.fi>

 On Thu Nov 18 1999 at 01:15:02 +0100, Hubert Feyrer wrote:
 | On Wed, 17 Nov 1999, Erik Fair wrote:
 | > What do the other UNIX-like OSes (e.g. System V, AIX, IRIX) do? (I 
 | > don't have access to any of those these days, partly by choice).
 | 
 | miyu% ssh rfhsi8002 'uname -a ; grep nobody /etc/passwd /etc/group'
 | IRIX rfhsi8002 6.2 03131015 IP22
 | /etc/passwd:nobody:*:60001:60001:SVR4 nobody uid:/dev/null:/dev/null
 | /etc/passwd:nobody:*:-2:-2:original nobody uid:/dev/null:/dev/null
 | /etc/group:nobody:*:60001:

 IRIX video 6.5 07151440 IP32 mips
 /etc/passwd:nobody:*:60001:60001:SVR4 nobody uid:/dev/null:/dev/null
 /etc/passwd:nobody:*:60001:60001:original nobody uid:/dev/null:/dev/null
 /etc/group:nobody:*:60001:

 | > uname -a
 | AIX rfhpa8001 1 4 00224F18E000
 | > grep nobody /etc/passwd /etc/group
 | /etc/passwd:nobody:!:4294967294:4294967294::/:
 | /etc/group:nobody:!:4294967294:nobody,lpd

 AIX leka 3 4 002027596600
 /etc/passwd:nobody:*:529:529:Nobody:/:
 /etc/group:nobody:!:4294967294:nobody,lpd

 OSF1 rubiini.hut.fi V4.0 564.32 alpha
 /etc/passwd:nobodyV:*:60001:60001:anonymous SystemV.4 NFS user:/:
 /etc/passwd:nobody:*:65534:65534:anonymous NFS user:/:
 /etc/passwd:nobody:*:529:529:Nobody:/:

 SunOS anger 5.7 Generic_106542-05 i86pc i386 i86pc
 /etc/passwd:nobody:x:60001:60001:SVR4 nobody uid:/dev/null:/bin/sh
 /etc/passwd:nobody:x:-2:-2:original nobody uid:/dev/null:/bin/sh
 /etc/passwd:nobody:x:65534:65534:Unprivileged user:/:/bin/sh
 /etc/group:nobody:*:65534:

 HP-UX palisant B.11.00 A 9000/778 2004804704 two-user license
 /etc/passwd:nobody:*:-2:-2::/:
 /etc/passwd:nobody:*:529:529:Nobody:/:

 jaddajaddajadda, guess that the uid of nobody is not that standard.

 -- 
 Antti Kantee               Research Assistant                  B231
 pooka@cs.hut.fi        Helsinki Univ of Technology          PL 5400
 +358 9 451 5194   Lab of Information Processing Science   02015 TKK


 Date:	Thu, 18 Nov 1999 22:10:27 -0800
 From:	Erik Fair <security-officer@NetBSD.ORG>

 OK, I think I see the pattern here:

 1. nobody UID is "-2" (or an unsigned representation of same,
 bit-width dependent) which is consistent with default NFS mapping
 of root client access to an server.

 2. nobody UID is an arbitrary value.

 We currently fall into #2.

 Consistency issues aside, I think the main security issue (why I
 brought it up here) is whether having a "nobody" UID in /etc/passwd
 would encourage system administrators to set file/directory ownership
 to that UID, and, in the presence of NFS, does that present a
 security exposure?

 If we say "yes", then our current situation is OK, and we leave
 things as they are.

 If we say "no", then we should change "nobody" to "-2" for better
 consistency with the rest of the world (not to mention our own
 mountd). I did a cursory walk through libc to try and find the
 passwd file parser (it used to be in getpwent.c) and failed to find
 it; I was trying to check if it will accept a negative number in
 the UID and GID fields of /etc/passwd (and /etc/group).

 Any further thoughts along this line?

 	pondering ponderously,

 	Erik <fair@clock.org>

 Date:	Fri, 19 Nov 1999 02:04:40 -0500 (EST)
 From:	Curt Sampson <cjs@cynic.net>

 Personally, I think this is a good idea:

 OSF1 rubiini.hut.fi V4.0 564.32 alpha
 /etc/passwd:nobodyV:*:60001:60001:anonymous SystemV.4 NFS user:/:
 /etc/passwd:nobody:*:65534:65534:anonymous NFS user:/:
 /etc/passwd:nobody:*:529:529:Nobody:/:

 cjs
 --
 Curt Sampson  <cjs@cynic.net>   917 532 4208   De gustibus, aut bene aut nihil.
 The most widely ported operating system in the world: http://www.netbsd.org

 Date:	22 Nov 1999 21:34:50 -0500
 From:	root@ihack.net (Charles M. Hannum)

 Erik Fair <security-officer@NetBSD.ORG> writes:

 | If we say "no", then we should change "nobody" to "-2" for better 
 | consistency with the rest of the world (not to mention our own 
 | mountd).

 As the very least, with 32-bit uids, that will cause interesting quota
 file sizes...

 Date:	Sat, 27 Nov 1999 12:56:46 -0500 (EST)
 From:	woods@most.weird.com (Greg A. Woods)

 [ On Thursday, November 18, 1999 at 12:20:23 (+0200), Antti Kantee wrote: ]
 | Subject: Re: SunOS/Solaris "nobody" UID versus NetBSD's "nobody" UID
 |
 | jaddajaddajadda, guess that the uid of nobody is not that standard.

 It's actually not important that it be standard unless you create files
 owned by that UID and then expect to share them across NFS.

 Note that strictly speaking I think the idea is (was?) that "nobody"
 should never own anything or have any more than read (and sometimes
 execute) permission on any file anywhere in the exported NFS
 directories.  Unfortunately many developers and sys-admins have taken
 the lazy way out and many programs and systems can be found which
 default to using "nobody" as an application-specific private
 unprivileged user and often with the need to create and/or write to
 files that may themselves require protection from other "unprivileged"
 users.  Perhaps if "nobody" had been called "nfsroot" from day one there
 would have been less confusion.  Indeed with the current default uid/gid
 of -2 it is less likely for NFS remote root users to affect applications
 which are using the "nobody" user-id for their own purposes.

 What is important, at least from my point of view, is that the system
 default to mapping remote root accesses onto the same UID as is referred
 to as "nobody" in the (possibly local) passwd file (or perhaps "nfsroot"
 if we want to be brave and try to change the trend).  This probably
 means changing mountd so that it first tries to lookup the credentials
 for "nobody" (or "nfsroot") before it defaults to using "-2".  (Untested
 example patch attached.)

 The side issue is that if the magic number "-2" is going to continue to
 be the default value then there are some ``fixes'' necessary in the
 various library routines and utilities that do sanity checking on UIDs
 because currently some of them will not allow a value of -2.  It is of
 course only important to have a user-id with a uid of -2 if you want
 getpw() to be able to find user information for the default NFS
 unprivileged user (eg. if you do allow remote root users to create
 and/or write to some files in your exported filesystems and you want to
 identify these files by something other than the magic number "-2").  I
 think this is important in a general sense, but it may not be so
 important to everyone.

 -- 
 							Greg A. Woods

 +1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>

 ---------- untested example patch ----------

 (the second hunk is an unrelated minor fix)

 Index: mountd.c
 ===================================================================
 RCS file: /cvs/NetBSD/src/usr.sbin/mountd/mountd.c,v
 retrieving revision 1.1.1.4
 diff -c -c -r1.1.1.4 mountd.c
 *** mountd.c	1998/11/16 21:51:55	1.1.1.4
 --- mountd.c	1999/11/27 17:32:09
 ***************
 *** 1855,1863 ****
   	 * Set up the unpriviledged user.
   	 */
   	cr->cr_ref = 1;
 ! 	cr->cr_uid = -2;
 ! 	cr->cr_gid = -2;
 ! 	cr->cr_ngroups = 0;
   	/*
   	 * Get the user's password table entry.
   	 */
 --- 1855,1882 ----
   	 * Set up the unpriviledged user.
   	 */
   	cr->cr_ref = 1;
 ! 	if ((pw = getpwnam("nfsroot"))) {
 ! 		cr->cr_uid = pw->pw_uid;
 ! 		ngroups = NGROUPS + 1;
 ! 		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 ! 			syslog(LOG_ERR, "Too many groups for user: nfsroot");
 ! 		/*
 ! 		 * Convert from int's to gid_t's and compress out duplicate
 ! 		 */
 ! 		cr->cr_ngroups = ngroups - 1;
 ! 		cr->cr_gid = groups[0];
 ! 		for (cnt = 1; cnt < ngroups; cnt++)
 ! 			cr->cr_groups[cnt - 1] = groups[cnt];
 ! 	} else {
 ! 		/*
 ! 		 * assume default maproot to good old-fashioned "-2", though be
 ! 		 * warned that very few systems actually define a user-id with
 ! 		 * this value of uid.  Should this be syslog'ed?
 ! 		 */
 ! 		cr->cr_uid = -2;
 ! 		cr->cr_gid = -2;
 ! 		cr->cr_ngroups = 0;
 ! 	}
   	/*
   	 * Get the user's password table entry.
   	 */
 ***************
 *** 1878,1884 ****
   		cr->cr_uid = pw->pw_uid;
   		ngroups = NGROUPS + 1;
   		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 ! 			syslog(LOG_ERR, "Too many groups");
   		/*
   		 * Convert from int's to gid_t's and compress out duplicate
   		 */
 --- 1897,1903 ----
   		cr->cr_uid = pw->pw_uid;
   		ngroups = NGROUPS + 1;
   		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 ! 			syslog(LOG_ERR, "Too many groups for user: %s", name);
   		/*
   		 * Convert from int's to gid_t's and compress out duplicate
   		 */

 Date:	Sun, 28 Nov 1999 03:08:56 -0800
 From:	Erik Fair <fair@clock.org>

 How often is that section of code run?

 getpwnam(3) can turn into a YP or Kerberos(Hesiod) transaction,
 instead of just a quick db(3) lookup in a local password file. If
 that were run for every NFS access, it would be ... unfortunate.

 	Erik

 Date:	Sun, 28 Nov 1999 13:18:49 -0500 (EST)
 From:	woods@most.weird.com (Greg A. Woods)

 [ On Sunday, November 28, 1999 at 03:08:56 (-0800), Erik Fair wrote: ]

 | How often is that section of code run?

 It is only run at the time mountd starts and when it receives SIGHUP
 (i.e. when it's reading /etc/exports).

 -- 							Greg A. Woods
 +1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
 Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>


From: woods@weird.com (Greg A. Woods)
To: gnats-bugs@gnats.netbsd.org (NetBSD GNATS submissions and followups),
  netbsd-bugs@NetBSD.ORG (NetBSD Bugs and PR posting List)
Cc: gnats-admin@netbsd.org
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sat,  7 Sep 2002 15:36:49 -0400 (EDT)

 The following more complete patch has been tested (minimally) and should
 replace the previous patch I submitted to this PR.

 Note also the related fix in PR#18222 that is needed to allow the
 default -2/-2 user to be represented in /etc/master.passwd et al.

 These diffs are against the following revisions:

 	$ ident mountd.c exports.5
 	mountd.c:
 	     $NetBSD: mountd.c,v 1.77 2001/04/24 15:04:27 fvdl Exp $
 	     $NetBSD: mountd.c,v 1.77 2001/04/24 15:04:27 fvdl Exp $

 	exports.5:
 	     $NetBSD: exports.5,v 1.20 2001/04/03 11:27:01 wiz Exp $

 -- 
 								Greg A. Woods

 +1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

 Index: exports.5
 ===================================================================
 RCS file: /cvs/NetBSD/src/usr.sbin/mountd/exports.5,v
 retrieving revision 1.1.1.6
 diff -c -r1.1.1.6 exports.5
 *** exports.5	12 Jun 2001 21:26:50 -0000	1.1.1.6
 --- exports.5	7 Sep 2002 18:57:03 -0000
 ***************
 *** 33,39 ****
   .\"
   .\"     @(#)exports.5	8.3 (Berkeley) 3/29/95
   .\"
 ! .Dd March 29, 1995
   .Dt EXPORTS 5
   .Os
   .Sh NAME
 --- 33,39 ----
   .\"
   .\"     @(#)exports.5	8.3 (Berkeley) 3/29/95
   .\"
 ! .Dd September 7, 2002
   .Dt EXPORTS 5
   .Os
   .Sh NAME
 ***************
 *** 91,97 ****
   can still access the whole filesystem via individual RPCs if it
   wanted to, even if just one subdirectory has been mounted.
   The pathnames must not have any symbolic links in them and should not have
 ! any "." or ".." components.
   Mount points for a filesystem may appear on multiple lines each with
   different sets of hosts and export options.
   .Pp
 --- 91,101 ----
   can still access the whole filesystem via individual RPCs if it
   wanted to, even if just one subdirectory has been mounted.
   The pathnames must not have any symbolic links in them and should not have
 ! any
 ! .Dq \&.
 ! or
 ! .Dq \&..
 ! components.
   Mount points for a filesystem may appear on multiple lines each with
   different sets of hosts and export options.
   .Pp
 ***************
 *** 106,125 ****
   .Sm off
   .Fl maproot No = Sy user
   .Sm on
 ! The credential of the specified user is used for remote access by root.
 ! The credential includes all the groups to which the user is a member
 ! on the local machine (see
   .Xr id 1 ).
   The user may be specified by name or number.
   .Pp
   .Sm off
   .Fl maproot No = Sy user:group1:group2:...
   .Sm on
 ! The colon separated list is used to specify the precise credential
 ! to be used for remote access by root.
   The elements of the list may be either names or numbers.
 ! Note that user: should be used to distinguish a credential containing
 ! no groups from a complete credential for that user.
   .Pp
   .Sm off
   .Fl mapall No = Sy user
 --- 110,133 ----
   .Sm off
   .Fl maproot No = Sy user
   .Sm on
 ! The credential of the specified user is used for remote access by a
 ! client's superuser.  The credential includes all the groups to which the
 ! user is a member of on the local machine (see
   .Xr id 1 ).
   The user may be specified by name or number.
   .Pp
   .Sm off
   .Fl maproot No = Sy user:group1:group2:...
   .Sm on
 ! A colon separated list of a user and specific listed groups can be given
 ! to specify the precise credential and override the default groups the
 ! local user is a member of.
   The elements of the list may be either names or numbers.
 ! Note that
 ! .Dq user:
 ! can be used to distinguish a credential containing no groups from a
 ! complete credential for that user which would include the default groups
 ! that local user is a member of.
   .Pp
   .Sm off
   .Fl mapall No = Sy user
 ***************
 *** 128,135 ****
   .Sm off
   .Fl mapall No = Sy user:group1:group2:...
   .Sm on
 ! specifies a mapping for all client uids (including root)
 ! using the same semantics as
   .Fl maproot .
   .Pp
   The option
 --- 136,143 ----
   .Sm off
   .Fl mapall No = Sy user:group1:group2:...
   .Sm on
 ! specifies a mapping for all client user-IDs (including the remote
 ! superuser) using the same semantics as
   .Fl maproot .
   .Pp
   The option
 ***************
 *** 138,158 ****
   .Fl maproot
   in an effort to be backward compatible with older export file formats.
   .Pp
 ! In the absence of
   .Fl maproot
   and
   .Fl mapall
 ! options, remote accesses by root will result in using a credential of -2:-2.
 ! All other users will be mapped to their remote credential.
 ! If a
 ! .Fl maproot
 ! option is given,
 ! remote access by root will be mapped to that credential instead of -2:-2.
 ! If a
   .Fl mapall
 ! option is given,
 ! all users (including root) will be mapped to that credential in
 ! place of their own.
   .Pp
   The
   .Fl kerb
 --- 146,166 ----
   .Fl maproot
   in an effort to be backward compatible with older export file formats.
   .Pp
 ! In the absence of both
   .Fl maproot
   and
   .Fl mapall
 ! options, remote accesses by any client's superuser will use the
 ! credentials of the local
 ! .Dq nfsroot
 ! user, if one is defined in
 ! .Pa /etc/master.passwd ,
 ! or if not then they will use the credentials of
 ! .Dq -2:-2 .
 ! All other users will be mapped to their remote credential.  If a
   .Fl mapall
 ! option is given, all users (including remote superusers) will be mapped
 ! to that credential in place of their own.
   .Pp
   The
   .Fl kerb
 ***************
 *** 334,339 ****
 --- 342,348 ----
   .El
   .Sh SEE ALSO
   .Xr netgroup 5 ,
 + .Xr passwd 5 ,
   .Xr mountd 8 ,
   .Xr nfsd 8 ,
   .Xr showmount 8
 Index: mountd.c
 ===================================================================
 RCS file: /cvs/NetBSD/src/usr.sbin/mountd/mountd.c,v
 retrieving revision 1.1.1.8
 diff -c -r1.1.1.8 mountd.c
 *** mountd.c	12 Jun 2001 21:26:50 -0000	1.1.1.8
 --- mountd.c	7 Sep 2002 19:25:52 -0000
 ***************
 *** 235,244 ****
   static struct mountlist *mlhead;
   static struct grouplist *grphead;
   static char    *exname;
   static struct ucred def_anon = {
   	1,
 ! 	(uid_t) - 2,
 ! 	(gid_t) - 2,
   	0,
   	{}
   };
 --- 235,264 ----
   static struct mountlist *mlhead;
   static struct grouplist *grphead;
   static char    *exname;
 + 
 + #define DEF_ANON_USER	"nfsanon"	/* XXX should be just nobody?  But then
 + 					 * that would conflict with the many
 + 					 * other locally running applications
 + 					 * that assume they can use "nobody" as
 + 					 * their default user (eg. Apache,
 + 					 * squid, etc., etc.), and which
 + 					 * actually write to files as "nobody",
 + 					 * files which remote superusers should
 + 					 * not have access to!
 + 					 */
 + /*
 +  * If the DEF_ANON_USER doesn't exist then assume default maproot to good
 +  * old-fashioned "-2", though be warned that very few systems actually define a
 +  * user-id with these values of uid/gid (esp. since they are not allowed by the
 +  * old [GU]ID_MAX in <sys/syslimits.h>)
 +  */
 + #define DEF_ANON_GID	(-2)
 + #define DEF_ANON_UID	(-2)
 + 
   static struct ucred def_anon = {
   	1,
 ! 	(uid_t) DEF_ANON_UID,
 ! 	(gid_t) DEF_ANON_UID,
   	0,
   	{}
   };
 ***************
 *** 310,316 ****
   		exname = *argv;
   	else
   		exname = _PATH_EXPORTS;
 ! 	openlog("mountd", LOG_PID, LOG_DAEMON);

   	s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
   	if (s < 0)
 --- 330,336 ----
   		exname = *argv;
   	else
   		exname = _PATH_EXPORTS;
 ! 	openlog("mountd", LOG_PID | (debug ? LOG_PERROR : 0), LOG_DAEMON);

   	s = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
   	if (s < 0)
 ***************
 *** 929,935 ****
   	FILE *exp_file;
   	char *line;
   	size_t lineno = 0, len;
 ! 

   	/*
   	 * First, get rid of the old list
 --- 949,955 ----
   	FILE *exp_file;
   	char *line;
   	size_t lineno = 0, len;
 ! 	struct passwd *pw;

   	/*
   	 * First, get rid of the old list
 ***************
 *** 953,958 ****
 --- 973,1005 ----
   	grphead = NULL;

   	/*
 + 	 * reset the def_anon credential
 + 	 */
 + 	if ((pw = getpwnam(DEF_ANON_USER))) {
 + 		int ngroups, groups[NGROUPS + 1];
 + 
 + 		def_anon.cr_uid = pw->pw_uid;
 + 		ngroups = NGROUPS + 1;
 + 		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 + 			syslog(LOG_ERR, "Too many groups for user: %s", DEF_ANON_USER);
 + 		/*
 + 		 * Convert from int's to gid_t's and compress out duplicate
 + 		 */
 + 		def_anon.cr_ngroups = ngroups - 1;
 + 		def_anon.cr_gid = groups[0];
 + 		for (i = 1; i < ngroups; i++)
 + 			def_anon.cr_groups[i - 1] = groups[i];
 + 	} else {
 + 		syslog(LOG_INFO,
 + 		       "no default NFS anonymous user \"%s\" defined, using uid/gid of -2/-2",
 + 		       DEF_ANON_USER);
 + 		def_anon.cr_uid = DEF_ANON_UID;
 + 		def_anon.cr_gid = DEF_ANON_UID;
 + 		def_anon.cr_ngroups = 0;
 + 		for (i = 0; i < NGROUPS; i++)
 + 			def_anon.cr_groups[i] = 0;
 + 	}
 + 	/*
   	 * And delete exports that are in the kernel for all local
   	 * file systems.
   	 * XXX: Should know how to handle all local exportable file systems
 ***************
 *** 2151,2162 ****
   		memset(&hints, 0, sizeof hints);
   		hints.ai_family = AF_UNSPEC;
   		hints.ai_flags = AI_NUMERICHOST;
 ! 		if (getaddrinfo(cp, NULL, &hints, &ai) == 0)
   			sa = ai->ai_addr;
 ! 		else
   			goto fail;
 ! 	} else
   		goto fail;

   	/*
   	 * Only allow /pref notation for v6 addresses.
 --- 2198,2215 ----
   		memset(&hints, 0, sizeof hints);
   		hints.ai_family = AF_UNSPEC;
   		hints.ai_flags = AI_NUMERICHOST;
 ! 		if ((ecode = getaddrinfo(cp, NULL, &hints, &ai)) == 0)
   			sa = ai->ai_addr;
 ! 		else {
 ! 			if (debug)
 ! 				fprintf(stderr, "get_net: getaddrinfo() failed: %s.\n", gai_strerror(ecode));
   			goto fail;
 ! 		}
 ! 	} else {
 ! 		if (debug)
 ! 			fprintf(stderr, "get_net: getnetbyname() failed, unrecognized net name format.\n");
   		goto fail;
 + 	}

   	/*
   	 * Only allow /pref notation for v6 addresses.
 ***************
 *** 2166,2181 ****

   	ecode = getnameinfo(sa, sa->sa_len, netname, sizeof netname,
   	    NULL, 0, ninumeric);
 ! 	if (ecode != 0)
   		goto fail;

   	if (maskflg)
   		net->nt_len = countones(sa);
   	else {
   		if (opt_flags & OP_MASKLEN) {
 ! 			preflen = strtol(prefp, NULL, 10);
 ! 			if (preflen == LONG_MIN && errno == ERANGE)
   				goto fail;
   			net->nt_len = (int)preflen;
   			*p = '/';
   		}
 --- 2219,2240 ----

   	ecode = getnameinfo(sa, sa->sa_len, netname, sizeof netname,
   	    NULL, 0, ninumeric);
 ! 	if (ecode != 0) {
 ! 		if (debug)
 ! 			fprintf(stderr, "get_net: getnameinfo() failed: %s.\n", gai_strerror(ecode));
   		goto fail;
 + 	}

   	if (maskflg)
   		net->nt_len = countones(sa);
   	else {
   		if (opt_flags & OP_MASKLEN) {
 ! 			preflen = strtol(prefp, (char **) NULL, 10);
 ! 			if (preflen == LONG_MIN && errno == ERANGE) {
 ! 				if (debug)
 ! 					fprintf(stderr, "get_net: %s out of range.\n", prefp);
   				goto fail;
 + 			}
   			net->nt_len = (int)preflen;
   			*p = '/';
   		}
 ***************
 *** 2258,2267 ****
   	/*
   	 * Set up the unprivileged user.
   	 */
 ! 	cr->cr_ref = 1;
 ! 	cr->cr_uid = -2;
 ! 	cr->cr_gid = -2;
 ! 	cr->cr_ngroups = 0;
   	/*
   	 * Get the user's password table entry.
   	 */
 --- 2317,2323 ----
   	/*
   	 * Set up the unprivileged user.
   	 */
 ! 	*cr = def_anon;
   	/*
   	 * Get the user's password table entry.
   	 */
 ***************
 *** 2282,2288 ****
   		cr->cr_uid = pw->pw_uid;
   		ngroups = NGROUPS + 1;
   		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 ! 			syslog(LOG_ERR, "Too many groups");
   		/*
   		 * Convert from int's to gid_t's and compress out duplicate
   		 */
 --- 2338,2344 ----
   		cr->cr_uid = pw->pw_uid;
   		ngroups = NGROUPS + 1;
   		if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 ! 			syslog(LOG_ERR, "Too many groups for user: %s", name);
   		/*
   		 * Convert from int's to gid_t's and compress out duplicate
   		 */

From: David Laight <david@l8s.co.uk>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc: gnats-admin@NetBSD.ORG
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sat, 7 Sep 2002 21:57:16 +0100

 A couple of little things:

 > + #define DEF_ANON_GID	(-2)
 > + #define DEF_ANON_UID	(-2)

 Need casting to uid_t and gid_t or gcc might start bleating

 > + 	if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 > + 	 /* Convert from int's to gid_t's and compress out duplicate 

 getgrouplist is defined to have 'gid_t *groups' (in getgrouplist(3)
 and unistd.h, although the man page (still?) says 'the integer
 array pointed to by groups').  So this code isn't right...

 I've also been wondering....

 I presume (from where the changes are) that this is a server-side
 map of uid zero - ie the nfs packets contain 0 not -2.

 I was wondering whether the 'correct' fix isn't here, but is where
 file premissions are checked (access?).  There uid/gid values of
 -2 could explicitly not match any user or group.  So only if there
 is write access by 'other' would the values ever end up in the
 filesystem, indeed write permission could be revoked as well.

 There is then the question of whether specifying -mapall=nobody
 in /etc/exports should use -2:-2 or the password entry for "nobody"?
 Is -mapall=-2:-2 valid?
 What does -webnfs do?

 	David

 -- 
 David Laight: david@l8s.co.uk

From: woods@weird.com (Greg A. Woods)
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:  
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sat,  7 Sep 2002 17:30:07 -0400 (EDT)

 [ On Saturday, September 7, 2002 at 21:57:16 (+0100), David Laight wrote: ]
 > Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
 >
 > A couple of little things:
 > 
 > > + #define DEF_ANON_GID	(-2)
 > > + #define DEF_ANON_UID	(-2)
 > 
 > Need casting to uid_t and gid_t or gcc might start bleating

 Not my GCC.  :-)

 In any case I intended them to be cast when they are used, just as one
 would normally do if one didn't use a pre-defined manifest constant.  I
 really really really detest pre-concieved casts appearing in manifest
 contant definitions, even if such constants really are only intended to
 be used for one given data type.

 > > + 	if (getgrouplist(pw->pw_name, pw->pw_gid, groups, &ngroups))
 > > + 	 /* Convert from int's to gid_t's and compress out duplicate 
 > 
 > getgrouplist is defined to have 'gid_t *groups' (in getgrouplist(3)
 > and unistd.h, although the man page (still?) says 'the integer
 > array pointed to by groups').  So this code isn't right...

 That code simply copies a nearly identical fragment from further down in
 the same function.....

 > I've also been wondering....
 > 
 > I presume (from where the changes are) that this is a server-side
 > map of uid zero - ie the nfs packets contain 0 not -2.

 Yes, that's right.

 > I was wondering whether the 'correct' fix isn't here, but is where
 > file premissions are checked (access?).

 No, I don't think so.  The UID/GID mapping is set up by mountd.  The
 mapping for superuser->anonymous is just a special common case of the
 more general mapping now also allowed by the newer '-mapall' option.

 >  There uid/gid values of
 > -2 could explicitly not match any user or group.

 I'm sure what you mean by that.  Do you mean "their", as in "the
 client's uid/gid values of -2/-2"?

 If so then that's an irrelevant issue -- or rather it's a site-specific
 local configuration issue, not one mountd can deal with categorically.

 The mountd code needs to have some kind of default just in case the
 local user database doesn't contain a "nobody" (or whatever) user.
 "-2/-2" is just the de facto standard user-ID and group-ID for NFS
 anonymous access, traditionally I suppose because it was the "last"
 valid UID/GID possible (i.e. when treated as an unsigned integer value).

 The *BSD mountd code (and probably even the original Sun implementation
 too) in fact never before tried to default to some specific user (that's
 what my patch essentialy tries to address), but rather made the
 assumption that a user database entry for "-2/-2" would be defined by
 the server administrator, if desired.  Unfortunately it's never (in any
 NetBSD release) been possible to define a user with these credentials,
 and I suppose the *BSD mountd assumes everyone will use either
 "-maproot" or "-mapall" in all cases, even though such a requirement is
 never enforced.

 It's really irrelevant what any client might have as a user or group for
 the ID "-2".  In a configuration set up as intended by the original
 implementers I suppose the user and group databases would be shared via
 NIS/YP, but all that really matters is the server be able to map
 accesses by client superusers into some non-superuser ID.

 >  So only if there
 > is write access by 'other' would the values ever end up in the
 > filesystem, indeed write permission could be revoked as well.

 The general idea behind the NFS anonymous user is to map access
 credentials from remote superusers into some local UID which in general
 is least-privileged (i.e. owns no files and thus can only write to
 world-writable places).

 > There is then the question of whether specifying -mapall=nobody
 > in /etc/exports should use -2:-2 or the password entry for "nobody"?

 The password entry for "nobody", of course.

 > Is -mapall=-2:-2 valid?

 Sure (it should be, though I've not ever tried it).  Why do you think it
 would not be?

 > What does -webnfs do?

 Damned if I know -- I've never used it!  :-)

 -- 
 								Greg A. Woods

 +1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

From: David Laight <david@l8s.co.uk>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:  
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sat, 7 Sep 2002 22:58:15 +0100

 On Sat, Sep 07, 2002 at 05:30:07PM -0400, Greg A. Woods wrote:
 > Not my GCC.  :-)

 No, but the new one Jason is playing with might.
 It generated rather a lot of signed/unsigned warnings he's been fixing.

 > In any case I intended them to be cast when they are used,
 Why? I actually dislike casts - they are too powerful for most places [1].
 Since these are constants of type uid_t they really ought to be in
 the domain of the type.  Otherwise you might as well just use -2, at
 least then it is obvious what is going on....

 > > I was wondering whether the 'correct' fix isn't here, but is where
 > > file premissions are checked (access?).
 > 
 > No, I don't think so.  The UID/GID mapping is set up by mountd.  The
 > mapping for superuser->anonymous is just a special common case of the
 > more general mapping now also allowed by the newer '-mapall' option.
 > 
 > >  There uid/gid values of
 > > -2 could explicitly not match any user or group.
 > 
 > I'm sure what you mean by that.  Do you mean "their", as in "the
 > client's uid/gid values of -2/-2"?

 No, "there, ..." as in where the permissions are checked.

 > The mountd code needs to have some kind of default just in case the
 > local user database doesn't contain a "nobody" (or whatever) user.

 No: the default (checked man page again) is -maproot=-2:-2
 not -maproot=nobody.

 > It's really irrelevant what any client might have as a user or group for
 > the ID "-2".  In a configuration set up as intended by the original
 > implementers I suppose the user and group databases would be shared via
 > NIS/YP, but all that really matters is the server be able to map
 > accesses by client superusers into some non-superuser ID.

 Does NFS predate NIS/YP?  It could easily ...

 > The general idea behind the NFS anonymous user is to map access
 > credentials from remote superusers into some local UID which in general
 > is least-privileged (i.e. owns no files and thus can only write to
 > world-writable places).

 Yes - I was wondering whether that ought to be tightly enforced?
 ie even if a file has uid -2 it still can't be accessed?
 The permissions for created files become problematical...

 > > Is -mapall=-2:-2 valid?
 > 
 > Sure (it should be, though I've not ever tried it).  Why do you think it
 > would not be?

 I hadn't checked that numbers were valid, especially -ve ones :-)


 	David

 [1] mainly due to the ability to change pointers to integers, which is only
 required rairly.  I will sometimes define macros to do strongly typed
 casts, eg:
 #define SCHAR_TO_UCHAR(c) ((uchar *)0 + (c - (char *)0))
 Although inline functions have the same effect (in gcc).

 -- 
 David Laight: david@l8s.co.uk

From: woods@weird.com (Greg A. Woods)
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:  
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sat,  7 Sep 2002 18:22:50 -0400 (EDT)

 [ On Saturday, September 7, 2002 at 22:58:15 (+0100), David Laight wrote: ]
 > Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
 >
 > On Sat, Sep 07, 2002 at 05:30:07PM -0400, Greg A. Woods wrote:
 > > Not my GCC.  :-)
 > 
 > No, but the new one Jason is playing with might.
 > It generated rather a lot of signed/unsigned warnings he's been fixing.

 Not if they are cast when used, as intended.

 Of course in fact they're only used in assignments and a syslog() (well
 they're used in a syslog() in my even newer code :-), so even then I
 doubt even GCC 3.2 will complain, and if it does then casts can be added
 as required and appropriate.

 > > In any case I intended them to be cast when they are used,
 > 
 > Why? I actually dislike casts - they are too powerful for most places [1].

 You can dislike them if you like but they're much better used where
 necessary and I don't think they should ever be encoded into a manifest
 constant defintion as you were suggesting they should be!  I really
 dislike _unnecessary_ casts.

 > Since these are constants of type uid_t they really ought to be in
 > the domain of the type.

 Actually they're in the domain of (int), which is what I intended.

 >  Otherwise you might as well just use -2, at
 > least then it is obvious what is going on....

 No, they're used in multiple places -- _I_ definitely want a manifest
 constant integer to use, not some magic number.

 > > The mountd code needs to have some kind of default just in case the
 > > local user database doesn't contain a "nobody" (or whatever) user.
 > 
 > No: the default (checked man page again) is -maproot=-2:-2
 > not -maproot=nobody.

 Please go read the mountd.c code, and please go read the entire PR., not
 just the submission I added to it today.

 Please also read the patched (with todays patch) manual page too.

 The mountd code needs to have some default uid and gid to use in case
 the local user database doesn't contain a "nobody" (or "nfsanon", or
 whatever) user.  That means not only for my patched version which will
 try to first find an "nfsanon" user, but also for the pre-patched and
 default case where "-2/-2" is used.

 > > It's really irrelevant what any client might have as a user or group for
 > > the ID "-2".  In a configuration set up as intended by the original
 > > implementers I suppose the user and group databases would be shared via
 > > NIS/YP, but all that really matters is the server be able to map
 > > accesses by client superusers into some non-superuser ID.
 > 
 > Does NFS predate NIS/YP?  It could easily ...

 Perhaps, but regardless the appearance of NIS/YP is in part directly to
 address these kinds of issues (i.e. centralized management of UIDs that
 will be seen by multiple clients on distributed filesystems).

 > > The general idea behind the NFS anonymous user is to map access
 > > credentials from remote superusers into some local UID which in general
 > > is least-privileged (i.e. owns no files and thus can only write to
 > > world-writable places).
 > 
 > Yes - I was wondering whether that ought to be tightly enforced?
 > ie even if a file has uid -2 it still can't be accessed?

 Ah, _NO_!  :-)

 > The permissions for created files become problematical...

 Indeed!  Perhaps you should look at some clusters of diskless clients in
 real production use.  The client superusers must quite often be able to
 create files, and subsequently access the files they create, even on
 partitions where they do not have superuser access (and indeed in some
 cases they may not ever have any superuser access to any files on any
 filesystems).

 -- 
 								Greg A. Woods

 +1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>

From: David Laight <david@l8s.co.uk>
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:  
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sun, 8 Sep 2002 09:33:14 +0100

 > > Yes - I was wondering whether that ought to be tightly enforced?
 > > ie even if a file has uid -2 it still can't be accessed?
 > 
 > Ah, _NO_!  :-)
 > 
 > > The permissions for created files become problematical...
 > 
 > Indeed!  Perhaps you should look at some clusters of diskless clients in
 > real production use.  The client superusers must quite often be able to
 > create files, and subsequently access the files they create, even on
 > partitions where they do not have superuser access (and indeed in some
 > cases they may not ever have any superuser access to any files on any
 > filesystems).

 It is a long time since I've had access to such a cluster (sun3s)
 and I didn't set it up.  However under those circumstances the admin
 would almost certainly explicitely map remote root access to a
 specific local user.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: woods@weird.com (Greg A. Woods)
To: NetBSD GNATS submissions and followups <gnats-bugs@gnats.netbsd.org>,
  NetBSD Bugs and PR posting List <netbsd-bugs@NetBSD.ORG>
Cc:  
Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
Date: Sun,  8 Sep 2002 13:56:02 -0400 (EDT)

 [ On Sunday, September 8, 2002 at 09:33:14 (+0100), David Laight wrote: ]
 > Subject: Re: security/6594: the default "nobody" credentials (32767:9999) do not match mountd's default (-2:-2)
 >
 > > > Yes - I was wondering whether that ought to be tightly enforced?
 > > > ie even if a file has uid -2 it still can't be accessed?
 > > 
 > > Ah, _NO_!  :-)
 > > 
 > > > The permissions for created files become problematical...
 > > 
 > > Indeed!  Perhaps you should look at some clusters of diskless clients in
 > > real production use.  The client superusers must quite often be able to
 > > create files, and subsequently access the files they create, even on
 > > partitions where they do not have superuser access (and indeed in some
 > > cases they may not ever have any superuser access to any files on any
 > > filesystems).
 > 
 > It is a long time since I've had access to such a cluster (sun3s)
 > and I didn't set it up.  However under those circumstances the admin
 > would almost certainly explicitely map remote root access to a
 > specific local user.

 I should probably point out that the NFS anonymous user is used not just
 for remote client superusers, but if I understand things correctly (and
 my understanding is still based more on knowledge of SunOS-4 NFS than on
 the NFS implementation in NetBSD), for all "anonymous" users -- the
 remote superuser is simply treated as an anonymous user.  In other words
 the "-maproot" option is a mis-nomer and it would better be "-anon" just
 as it was for SunOS-4 exportfs.

 So, what's the difference between an explict mapping of remote client
 anonymous access credentials, and the default mapping of "-2/-2"?  In
 fact there is none.

 The whole point is that the _default_ anonymous uid/gid for mountd(8) is
 still -2/-2, even with my patch in the case where the server doesn't
 have the "nfsanon" user.  Mountd must either have a default, or it must
 completely and totally fail to operate.  The use of a default allows it
 to continue to operate with only a minimal risk of causing problems.
 That uid/gid pair is perfectly valid as a default and has been for many
 years and for many systems (which makes it even more desirable to keep
 as the default, eg. where there are clusters of heterogeneous servers
 which can still only use those values, eg. perhaps AIX, HP-UX, etc., and
 which cross-mount each other's local storage).

 Your idea to have the kernel refuse any write permissions to '-2/-2' is
 simply not founded in any way on the actual goals of mapping anonymous
 remote client users to some local user.  The _default_ NFS anonymous
 user is simply chosen so as to be well out of the way of any proper
 user, even if there's no definition of this user in the local user
 database, thus reducing the risk that it collide and give some remote
 client undue privileges.  The choice of representation as "-2/-2" is
 simply of one of convenience.  The fact remains that except for the one
 reserved value needed by one(?) broken API that on a twos compliment
 machine happens to match "-1", user-IDs are unsigned integer values and
 so taking into account that "-1" is the same as UINT_MAX, "-2" is the
 opposite end of the range of valid values farthest from the superuser at
 "0".

 (Note in SunOS-4 "exportfs -anon=-1" was supposed to disable all
 anonymous access, and thus IIUC, access by remote client superusers
 too.  I don't know if that concept is embodied in the *BSD
 implementation -- it's certainly not documented.)

 -- 
 								Greg A. Woods

 +1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
 Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/6594 CVS commit: src/usr.sbin/mountd
Date: Sat, 19 Jan 2008 23:01:36 +0000 (UTC)

 Module Name:	src
 Committed By:	dholland
 Date:		Sat Jan 19 23:01:36 UTC 2008

 Modified Files:
 	src/usr.sbin/mountd: mountd.c

 Log Message:
 Improve an error message. Was buried in PR 6594 from Greg A. Woods.


 To generate a diff of this commit:
 cvs rdiff -r1.113 -r1.114 src/usr.sbin/mountd/mountd.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.