--3V7upXqbjpZ4EhLz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 26, 2007 at 03:05:06PM -0500, Eric Haszlakiewicz wrote:
> On Wed, Jul 25, 2007 at 10:57:53PM -0700, Bill Stouder-Studenmund wrote:
> > We should check, but I doubt there is a security issue here. All you're=
=20
> > going to find is anything extra you scribbled while the page was in cac=
he.=20
> > And you have to have write access to do that, so you could have written=
=20
> > the file anyway.
>=20
> Sure, but anyone with read access can see that data.  You don't need write
> access for that.  You can even do it with cp:

I'm sorry, but I still don't see how this is a security issue. You're=20
playing with mmap and bytes past the end of the file. "Don't do that."

> ./a.out   # run my test program
> perl -e 'truncate("test", 16);'    # make the file one byte longer

Actualy, this probably is a bug. From truncate(2):

     truncate() causes the file named by path or referenced by fd to have a
     size of length bytes.  If the file previously was larger than this siz=
e,
     the extra data is discarded.  If it was previously shorter than length,
     its size is increased to the specified value and the extended area
     appears as if it were zero-filled.

So I think that's a bug.

Take care,

Bill

--3V7upXqbjpZ4EhLz
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGqXZiWz+3JHUci9cRAgfHAJ0aHYzH4f48Y+1wGlUJ3NlkDBJbWACffqIm
kL1HNbzfXiV8RV1U5PB3eoo=
=43GM
-----END PGP SIGNATURE-----

--3V7upXqbjpZ4EhLz--