From owner-freebsd-current@FreeBSD.ORG Tue Feb 19 09:31:47 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 873DB772 for ; Tue, 19 Feb 2013 09:31:47 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 41FC9B3D for ; Tue, 19 Feb 2013 09:31:46 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1U7jY7-0006IZ-4y; Tue, 19 Feb 2013 11:31:43 +0200 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 12C4C1CC1E; Tue, 19 Feb 2013 11:31:43 +0200 (EET) Date: Tue, 19 Feb 2013 11:31:42 +0200 From: Andrey Simonenko To: Elias Martenson Subject: Re: Possible bug in NFSv4 with krb5p security? Message-ID: <20130219093142.GA1459@pm513-1.comsys.ntu-kpi.kiev.ua> References: <477291850.3084864.1361113135205.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2013-02-19 11:31:43 X-Connected-IP: 10.18.52.101:48741 X-Message-Linecount: 79 X-Body-Linecount: 61 X-Message-Size: 2983 X-Body-Size: 2071 Cc: Rick Macklem , Benjamin Kaduk , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:31:47 -0000 On Tue, Feb 19, 2013 at 12:06:13AM +0800, Elias Martenson wrote: > > You were right, the problem was in pname_to_uid.c. In it, the following > code can be found: > > char lname[MAXLOGNAME + 1], buf[1024]; > > /* some code snipped for brevity... */ > > getpwnam_r(lname, &pwd, buf, sizeof(buf), &pw); > if (pw) { > *uidp = pw->pw_uid; > return (GSS_S_COMPLETE); > } else { > return (GSS_S_FAILURE); > } > > As it turns out, the getpwnam_r() call fails with ERANGE (I had to check > the return value from getpwnam_r() in order to determine this, as pw is set > to NULL both if there was an error or if the user name can't be found). > > Now, increasing the size of buf to 1024 solved the problem, and now the > lookup works correctly. > > I wrote a small test program that issued the same call to getpwnam_r() and > it worked. Until I su'ed to root, and then it failed. > > It seems as though the buffer needs to be bigger if you're root. I have no > idea why, but there you have it. Problem solved. It can require bigger buffer, since root can get the pw_password field in the struct passwd{}. Since sysconf(_SC_GETPW_R_SIZE_MAX) does not work on FreeBSD, the buffer for getpwnam_r() call should have at least (2 * MAXLOGNAME + 2 * MAXPATHLEN + _PASSWORD_LEN + 1) bytes (it is unclear how much is required for pw_gecos). This buffer can be dynamically reallocated until getpwnam_r() is not return ERANGE error (the following code has not been compiled and verified): #define PWBUF_SIZE_INI (2 * MAXLOGNAME + 2 * MAXPATHLEN + _PASSWORD_LEN + 1) #define PWBUF_SIZE_INC 128 size = PWBUF_SIZE_INI; for (;;) { size += PWBUF_SIZE_INC; buf = malloc(size); if (buf == NULL) return (GSS_S_FAILURE); error = getpwnam_r(lname, &pwd, buf, size, &pw); free(buf); if (pw != NULL) { *uidp = pw->pw_uid; return (GSS_S_COMPLETE); } else { if (error == ERANGE && size <= SIZE_MAX - PWBUF_SIZE_INC) continue; return (GSS_S_FAILURE); } }