Re: [PATCH 3/8] Add support for a generic wal reading facility dubbed XLogReader

Tom Lane escribió:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> > On Tuesday, October 30, 2012 03:20:03 PM Alvaro Herrera wrote:
> >> Am I the only one who finds this rather bizarre? Maybe this was okay
> >> when xlog data would only come from WAL files stored in the data
> >> directory at recovery, but if we're now receiving these from a remote
> >> sender over the network I wonder if we should be protecting against
> >> malicious senders. (This is not related to this patch anyway.)
>
> > You can't use a CRC against malicous users anyway, its not cryptographically
> > secure in any meaning of the word,
>
> More to the point, if a bad guy has got control of your WAL stream,
> crashing the startup process with a ridiculous length word is several
> orders of magnitude less than the worst thing he can find to do to you.
> So the above argument seems completely nonsensical to me.

Well, I wasn't talking just about the record length, but about the
record in general. The length just came up because it's what I noticed.

And yeah, I was thinking in one sum for the header and another one for
the data. If we're using CRC to detect end of WAL, what sense does it
make to have to read the whole record if we can detect the end by just
looking at the header? (I obviously see that we need to checksum the
data as well; and having a second CRC field would bloat the record.)

> Anybody who's worried about that type of scenario is better advised to
> be setting up SSL to ensure that the stream is coming from the server
> they think it's coming from.

Okay.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services