Date: Thu, 28 Feb 2008 11:05:23 +0100 From: "Frank Behrens" <frank@pinky.sax.de> To: arch@freebsd.org Subject: Re: Cleaning up FILE in stdio.. Message-ID: <200802281005.m1SA5Neb027352@post.frank-behrens.de> In-Reply-To: <20080228083555.GX83599@server.vk2pj.dyndns.org> References: <200802271138.33979.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Jeremy <peterjeremy@optushome.com.au> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200802281005.m1SA5Neb027352>