From owner-cvs-all@FreeBSD.ORG Sat Sep 29 02:12:00 2007 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 476E516A418; Sat, 29 Sep 2007 02:12:00 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from mail.farley.org (farley.org [67.64.95.201]) by mx1.freebsd.org (Postfix) with ESMTP id D5FA613C447; Sat, 29 Sep 2007 02:11:59 +0000 (UTC) (envelope-from scf@FreeBSD.org) Received: from thor.farley.org (thor.farley.org [192.168.1.5]) by mail.farley.org (8.14.1/8.14.1) with ESMTP id l8T2Bphh036602; Fri, 28 Sep 2007 21:11:51 -0500 (CDT) (envelope-from scf@FreeBSD.org) Date: Fri, 28 Sep 2007 21:11:51 -0500 (CDT) From: "Sean C. Farley" To: Bruce Evans In-Reply-To: <20070925044617.O54030@delplex.bde.org> Message-ID: References: <200709220230.l8M2UiRK020609@repoman.freebsd.org> <86r6krqbrd.fsf@ds4.des.no> <20070922202914.B90809@besplex.bde.org> <20070925044617.O54030@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_DOB,RCVD_IN_DOB,URIBL_RHS_DOB autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.farley.org Cc: =?ISO-8859-15?Q?Dag-Erling_Sm=F8rgrav?= , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/stdlib getenv.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Sep 2007 02:12:00 -0000 On Tue, 25 Sep 2007, Bruce Evans wrote: > On Sat, 22 Sep 2007, Sean C. Farley wrote: > >> On Sat, 22 Sep 2007, Bruce Evans wrote: >>> ... >>> Partial analysis: >>> - the size_t variable must have a small value that is representable >>> as an int (else casting it to int would be a bug and/or printing a >>> line of that length would be a style bug). >> >> What would be a good maximum that would fit style? Although still >> fairly big, NL_TEXTMAX for the entire line looks plausible. > > 79 less the length of all other text on the line :-). See below. * snip * >> Hopefully, no environment variables (name=value string) are anywhere >> close in size to size_t. :) > > Ah I see where the value comes from. A malicous user could probably > put > INT_MAX bytes in a single string in the environment on machines > with 32-bit ints, 64 bit address space and lots of RAM, and then > fork() but not exec(). That's close enough to user input for me. See below. * snip * > A more refined version would use something like strvis(), and could > use a smaller limit (with long corrupt strings indicated something > likje debuggers print long binary strings) since this this is only > debugging code, but *env.c is already too large for me. OK. I accepted the challenge to see how hard it would be. Here is a small ;) sample program[1] that fits the bill. Features: - Encodes characters using vis() to protect the tty. - Limits display to 79 characters taking into account encoding. - Shows a continuation string "..." if the string is too long. Unfortunately, it is not small nor simple. The encoding of characters really adds complexity to the function due to variable sizes of encodings. Of course, I could have used strvis(), but that would have limited the number of characters printed to 1/4 of the available space (less than 40 characters based upon the length of the program name) even if no encoding was necessary. I think it would have been easier to just put a '.' in any non-printable character's position. I will see if there is a better way. Sean 1. http://www.farley.org/freebsd/tmp/safe_display.c -- scf@FreeBSD.org