On 2013-05-30 08:02:56 -0400, Robert Haas wrote:
> On Thu, May 30, 2013 at 7:13 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> Surely this is undue pessimism.
> >
> > Why? The spec doesn't specify that case and that very well allows other
> > behaviour. Glibc sure does behave sensibly and zeroes the data
> > (sysdeps/posix/posix_fallocate64.c for the generic implementation) and
> > so does linux' fallocate() syscall, but that doesn't say much about
> > other implementations.
> >
> > None of the manpages I could find, nor the spec says anything about the
> > file's contents in the extended range. Given there were at least three
> > manpages of different origins that didn't specify that behaviour I am
> > not too optimistic. Why they didn't specify that completely obvious
> > question is hard to understand from my pov.
>
> I think they didn't specify it because it IS obvious. As Stephen
> says, it's been understood for decades that allowing unzeroed pages to
> be reallocated to some other file is a major security hole. I think
> we can assume that no credible OS does that. If there's some OS out
> there that chooses to fill the pre-extended pages with 0x55 or cat
> /dev/urandom instead of 0x00, they probably deserve what they get.
> It's hard for me to be believe that anything that silly actually
> exists.
I don't think there's much danger of getting uninitialized data or
such. That clearly would be insane. I think somebody might interpret it
as read(2) returning an error until the page has been written to which
isn't completely crazy.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
