Re: Patch: Initialise new file space to zero for Beos

[Jeffrey A Law <law at cygnus dot com>]

  In message <199909201346.GAA02460@toadfish.ninemoons.com>you write:
  > Given that this BeOS feature is also a potential security hole, it is
  > possible that the low level BeOS behavior may change.  This would make
  > the original patch Nick provided for bfd, as well as the current
  > proposed change, unnecessary.  For the moment I think we can live with
  > the bfd change, even if we have to maintain it as a Be local change to
  > the tools.  If indeed the low level behavior of BeOS will NOT change,
  > then the more general solution of wedging zero_fseek into the tools
  > via the libiberty library may be a better longterm solution.
  > 
  > Note that the only bug we have observed in the tools to date is the
  > assembler writing random data to parts of object files that are
  > allocated by seeking past the current end of the file and then never
  > overwritten with "real data".
While the only bug you have observed may be the gas bug, you've got a fairly
large security hole.

What's to stop joe badguy from playing the fseek trick to grab a bunch of 
disk blocks, then examine them for things he isn't supposed to see?  I
would never trust any of my personal data to a system that didn't scrub blocks
free blocks it gave to users.

This kind of hole was fixed on most systems 10-20 years ago.

The way I see it, you have two choices.  Scrub in the OS, or scrub at the
application.  The former is secure, the latter is not.  The former works
even for clueless programmers, the latter does not.

jeff