From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 26 17:19:46 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56D89106564A for ; Wed, 26 Oct 2011 17:19:46 +0000 (UTC) (envelope-from cjr@cruwe.de) Received: from cruwe.de (cruwe.de [188.40.164.98]) by mx1.freebsd.org (Postfix) with ESMTP id DE46F8FC08 for ; Wed, 26 Oct 2011 17:19:45 +0000 (UTC) Received: from cruwe.de (unknown [127.0.0.4]) by cruwe.de (Postfix) with ESMTP id 5F5AD28C18 for ; Wed, 26 Oct 2011 17:19:44 +0000 (UTC) Received: by cruwe.de (Postfix, from userid 65534) id 40B9E28C17; Wed, 26 Oct 2011 17:19:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.cruwe.de X-Spam-Level: X-Spam-Status: No, score=-1.0 required=4.0 tests=ALL_TRUSTED autolearn=unavailable version=3.3.1 Received: from dijkstra (p5B37B3C0.dip.t-dialin.net [91.55.179.192]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by cruwe.de (Postfix) with ESMTPSA id 11E1828C14 for ; Wed, 26 Oct 2011 17:19:41 +0000 (UTC) Date: Wed, 26 Oct 2011 19:19:41 +0200 From: "Christopher J. Ruwe" To: freebsd-hackers@freebsd.org Message-ID: <20111026191941.004d5889@dijkstra> In-Reply-To: <20111025212738.GJ93709@dan.emsphone.com> References: <20111023235231.71f73ea3@dijkstra> <20111024001034.GE93709@dan.emsphone.com> <20111024213140.491467d9@dijkstra> <20111024204209.GF93709@dan.emsphone.com> <20111025220725.7327fd57@dijkstra> <20111025212738.GJ93709@dan.emsphone.com> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV on mail.cruwe.de using ClamSMTP Subject: Re: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 17:19:46 -0000 On Tue, 25 Oct 2011 16:27:38 -0500 Dan Nelson wrote: > In the last episode (Oct 25), Christopher J. Ruwe said: > > On Mon, 24 Oct 2011 15:42:10 -0500 > > Dan Nelson wrote: > > > In the last episode (Oct 24), Christopher J. Ruwe said: > > > > On Sun, 23 Oct 2011 19:10:34 -0500 > > > > Dan Nelson wrote: > > > > > In the last episode (Oct 23), Christopher J. Ruwe said: > > > > > > I need to get the maximum size of an pwd-entry to determine > > > > > > the correct buffersize for calling getpwnam_r("uname",&pwd, > > > > > > buf, bufsize, &pwdp). I would like to use > > > > > > sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which > > > > > > unfornutately fails (returns -1). Currently, I used 16384, > > > > > > which seems to be too much, bit works for the time being. > > > [..] > > > > > From looking at the libc/gen/getpwent.c file, it looks like a > > > > > maximum size might be 1MB. The wrapper functions that convert > > > > > getpw*_r functions into ones that simply return a pointer to > > > > > malloced data all use the getpw() helper function, which > > > > > starts with a 1k buffer and keeps doubling its size until the > > > > > data fits or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX > > > > > is only checked within that getpw() function, though, so it's > > > > > possible that an nss library might return an even longer > > > > > string to a get*_r call. It's up to you to decide what your > > > > > own limit is :) > > > > > > > > Uh ... it's just that I hoped I had not to decide ;-) > > > > > > The getpwnam_r function needs enough space to store the "struct > > > passwd" itself (which has a constant size) plus the strings > > > pointed to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. > > > If you have enough control over your environment that you can > > > guarantee that the sum of those strings won't be larger than 4k, > > > then you can just used a fixed buffer of that size. Even 1k is > > > probably large enough for 99.999% of all systems. That's a > > > really long home directory or shell path :) On the other hand, > > > the GECOS field is theoretially free-form and could contain a lot > > > of data. I've never see it hold more than an office number > > > myself, though. > > > > > > > Thanks for your help so far. Just assuming (I am not sufficiently > > clear about myself and my own intents) I want to be precise and am > > afraid of guessing: Can I assume that the gecos field is an entry > > in /etc/passwd and can therefore never exceed LINE_MAX, i.e., 2048B > > (limits.h, line 72)? Or, more precisely, ( 2048B - sum( lenght(all > > fields except passwd) ) )? Would that be an acceptable limit to set > > the getpwnam_r( ... ) buffer to and/or would that be an acceptable > > value to replace the following bit from sysconf.c? > > > > 372 #if _POSIX_THREAD_SAFE_FUNCTIONS > -1 > > 373 case _SC_GETGR_R_SIZE_MAX: > > 374 case _SC_GETPW_R_SIZE_MAX: > > 375 #error "somebody needs to implement this" > > 376 #endif > > If your nsswitch.conf has "passwd: files" in it, then yes, you can > assume that the 2048-byte limit applies. However, if you are using > nss_ldap, nss_mysql, nss_winbind, or some other nsswitch module that > provides user info, that backend user system may be capable of > returning longer strings. If you want to be able to handle any struct > passwd that might be thrown at you, you should implement a "retry > with doubling" loop similar to the one in > libc/gen/getpwent.c:getpw() . This method has been suggested at some other sites as well ... I just had hopes it would be able to implement that in a more elegant and more concise manner. Anyways, thank you for your kind help, cheers, -- Christopher J. Ruwe TZ GMT + 2