From owner-freebsd-arch@FreeBSD.ORG Thu Feb 28 10:15:32 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20A8E1065672 for ; Thu, 28 Feb 2008 10:15:32 +0000 (UTC) (envelope-from frank@pinky.sax.de) Received: from post.frank-behrens.de (post.frank-behrens.de [82.139.255.138]) by mx1.freebsd.org (Postfix) with ESMTP id 767C78FC2E for ; Thu, 28 Feb 2008 10:15:31 +0000 (UTC) (envelope-from frank@pinky.sax.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pinky.sax.de; h=from:to:date:mime-version:subject:in-reply-to:references:content-type:content-transfer-encoding:content-description; q=dns/txt; s=pinky1; t=1204193126; i=frank@pinky.sax.de; bh=pkThCzbjZWWKTnb/NNMf0gWNcDg2Xb0SdoXRu7IKaoc=; b=u+qnvOwJHcLrwyqUjVjodENW7NOxOXtpezKBnd72N9bKWKf0Sola2DSEq/BgYFhgWcceYVDMRTfMaeKjvSR+3w== Received: from [192.168.20.32] (sun.behrens [192.168.20.32]) by post.frank-behrens.de (8.14.2/8.14.2) with ESMTP-MSA id m1SA5Neb027352 for ; Thu, 28 Feb 2008 11:05:23 +0100 (CET) (envelope-from frank@pinky.sax.de) Message-Id: <200802281005.m1SA5Neb027352@post.frank-behrens.de> From: "Frank Behrens" To: arch@freebsd.org Date: Thu, 28 Feb 2008 11:05:23 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <20080228083555.GX83599@server.vk2pj.dyndns.org> References: <200802271138.33979.jhb@freebsd.org> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Hashcash: 1:24:080228:arch@freebsd.org::B2cy8Dai19qayeA7:SQkB Cc: Subject: Re: Cleaning up FILE in stdio.. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2008 10:15:32 -0000 Peter Jeremy wrote on 28 Feb 2008 19:35: > On Wed, Feb 27, 2008 at 11:38:33AM -0500, John Baldwin wrote: >... > >think we can get away with renaming '_file' to '_ofile' and adding a new 'int > >_file' at the bottom of the struct and making sure '_ofile' is always in sync > >(when possible, truncated when _file is too bug). > > Truncation opens up the possibility that old executables could fopen() > lots of files (without getting any indication of a problem) and then > use fileno() to reference a truncated _ofile - causing it to access > some totally unrelated file. Admittedly, that is no worse than would > happen today. Is it possible and useful to read the compiled in version information for executables as it is done in kernel signal handling? Old executables could receive an error in case of truncation and newer executables access always the extended field. Just an idea, not sure if it works. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available.