Re: [PATCHES] [GENERAL] Forgot to dump old data before re-installing machine
"Dave Page" <[EMAIL PROTECTED]> writes: > On 18/01/2008, Peter Eisentraut <[EMAIL PROTECTED]> wrote: >> I didn't follow how the user got into this mess, so I don't know whether the >> suggestion "you need to initdb" is appropriate. > I would think not, as you almost certainly must be doing a file level > restore of the data directory to get into this state and therefore > probably want to keep your data. You could argue that that's true if there's an incompatible pg_control file there at all; I'm not sure why wrong-endianness is different from wrong-version or wrong-datetime-option or anything else. IIRC the HINT to initdb was originally kind of pointed at developers who'd just downloaded a new CVS update with a new catversion number. It might not be so appropriate for the field. The worst case scenario would be someone blindly following the hint and blowing away their old data ... regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [GENERAL] Forgot to dump old data before re-installing machine
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Here is a possible patch. Example output: > $ pg-install/bin/postgres -D pg-install/var/data > FATAL: database files are incompatible with server > DETAIL: The database cluster was initialized with PG_CONTROL_VERSION > 1090715648 (0x4103), but the server was compiled with PG_CONTROL_VERSION > 833 (0x0341). > HINT: This could be a mismatched byte order. It looks like you need to > initdb. > I didn't follow how the user got into this mess, so I don't know whether the > suggestion "you need to initdb" is appropriate. I think it still is, at least as much as it is in other situations where we say that. I didn't like the wording of the other part of the hint though. Maybe "This could be a problem of mismatched byte ordering"? Other than that quibble, +1. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [GENERAL] Forgot to dump old data before re-installing machine
On 18/01/2008, Peter Eisentraut <[EMAIL PROTECTED]> wrote: > Tom Lane wrote: > > What would work better is to add some code that checks whether > > pg_control_version looks like the byte-swap of a small number, > > and prints a suitably modified error message if so. > > Here is a possible patch. Example output: > > $ pg-install/bin/postgres -D pg-install/var/data > FATAL: database files are incompatible with server > DETAIL: The database cluster was initialized with PG_CONTROL_VERSION > 1090715648 (0x4103), but the server was compiled with PG_CONTROL_VERSION > 833 (0x0341). > HINT: This could be a mismatched byte order. It looks like you need to > initdb. > > I didn't follow how the user got into this mess, so I don't know whether the > suggestion "you need to initdb" is appropriate. I would think not, as you almost certainly must be doing a file level restore of the data directory to get into this state and therefore probably want to keep your data. /D ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [GENERAL] Forgot to dump old data before re-installing machine
Tom Lane wrote:
> What would work better is to add some code that checks whether
> pg_control_version looks like the byte-swap of a small number,
> and prints a suitably modified error message if so.
Here is a possible patch. Example output:
$ pg-install/bin/postgres -D pg-install/var/data
FATAL: database files are incompatible with server
DETAIL: The database cluster was initialized with PG_CONTROL_VERSION
1090715648 (0x4103), but the server was compiled with PG_CONTROL_VERSION
833 (0x0341).
HINT: This could be a mismatched byte order. It looks like you need to initdb.
I didn't follow how the user got into this mess, so I don't know whether the
suggestion "you need to initdb" is appropriate.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
diff -ur ../cvs-pgsql/src/backend/access/transam/xlog.c ./src/backend/access/transam/xlog.c
--- ../cvs-pgsql/src/backend/access/transam/xlog.c 2008-01-05 11:58:44.0 +0100
+++ ./src/backend/access/transam/xlog.c 2008-01-18 20:04:59.0 +0100
@@ -3888,6 +3888,16 @@
* of bytes. Complaining about wrong version will probably be more
* enlightening than complaining about wrong CRC.
*/
+
+ if (ControlFile->pg_control_version != PG_CONTROL_VERSION && ControlFile->pg_control_version % 65536 == 0 && ControlFile->pg_control_version / 65536 != 0)
+ ereport(FATAL,
+(errmsg("database files are incompatible with server"),
+ errdetail("The database cluster was initialized with PG_CONTROL_VERSION %d (0x%08x),"
+ " but the server was compiled with PG_CONTROL_VERSION %d (0x%08x).",
+ ControlFile->pg_control_version, ControlFile->pg_control_version,
+ PG_CONTROL_VERSION, PG_CONTROL_VERSION),
+ errhint("This could be a mismatched byte order. It looks like you need to initdb.")));
+
if (ControlFile->pg_control_version != PG_CONTROL_VERSION)
ereport(FATAL,
(errmsg("database files are incompatible with server"),
@@ -3895,6 +3905,7 @@
" but the server was compiled with PG_CONTROL_VERSION %d.",
ControlFile->pg_control_version, PG_CONTROL_VERSION),
errhint("It looks like you need to initdb.")));
+
/* Now check the CRC. */
INIT_CRC32(crc);
COMP_CRC32(crc,
diff -ur ../cvs-pgsql/src/bin/pg_controldata/pg_controldata.c ./src/bin/pg_controldata/pg_controldata.c
--- ../cvs-pgsql/src/bin/pg_controldata/pg_controldata.c 2007-04-03 22:26:13.0 +0200
+++ ./src/bin/pg_controldata/pg_controldata.c 2008-01-18 19:55:16.0 +0100
@@ -151,6 +151,11 @@
printf(_("pg_control version number:%u\n"),
ControlFile.pg_control_version);
+ if (ControlFile.pg_control_version % 65536 == 0 && ControlFile.pg_control_version / 65536 != 0)
+ printf(_("WARNING: possibly byte order mismatch\n"
+ "The byte order used to store the pg_control file might not match the one used\n"
+ "by this program. In that case the results below would be incorrect, and the\n"
+ "PostgreSQL installation would be incompatible with this data directory.\n"));
printf(_("Catalog version number: %u\n"),
ControlFile.catalog_version_no);
printf(_("Database system identifier: %s\n"),
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
On Fri, Jan 18, 2008 at 12:35:40PM +0100, Peter Eisentraut wrote: > Am Freitag, 18. Januar 2008 schrieb Magnus Hagander: > > Not that much more than moving the socket file to a secure directory. Both > > rely on configuring the client properly. It's arguably a lot easier to > > configure the client to connect to the correct socket, than to make sure > > the client has a root certificate installed. > > How would a client check whether the socket file is in a secure location? The same way it would get the root certificate to trust - it would be told so by the administrator who had secured the location. //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Freitag, 18. Januar 2008 schrieb Magnus Hagander: > Not that much more than moving the socket file to a secure directory. Both > rely on configuring the client properly. It's arguably a lot easier to > configure the client to connect to the correct socket, than to make sure > the client has a root certificate installed. How would a client check whether the socket file is in a secure location? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
On Fri, Jan 18, 2008 at 11:24:09AM +0100, Peter Eisentraut wrote: > Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan: > > I agree. I remain of the opinion that this is not a problem than can be > > solved purely within the bounds of postgres. > > Well, the SSL patch I showed certainly solves the problem. (I am not saying > it is the best possible solution.) Of course there also need to be prudent > users, but that is the case for any security system. Not that much more than moving the socket file to a secure directory. Both rely on configuring the client properly. It's arguably a lot easier to configure the client to connect to the correct socket, than to make sure the client has a root certificate installed. //Magnus ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Freitag, 18. Januar 2008 schrieb Alvaro Herrera: > I propose to create a dangling symlink on system startup in > /tmp/.s.PGSQL. to the real socket, which is not on a > world-writable directory. This avoids the spoofer, because he cannot > create the socket -- the symlink is occupying its place. This approaches the issue from the wrong end. Spoofing attacks the client, so the defense must be in the client. If the defense of the client is to rely on a carefully configured server, then that might exclude some possible attack vectors, but it is not a defense the client can rely on. To look at this in another way, if we relied on every browser user to type in web addresses correctly and all server administrators to make sure their "socket address" cannot be hijacked, we wouldn't need SSL on the web. The proper approach, however, is to configure the client to only talk to servers that can prove their identity. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Donnerstag, 17. Januar 2008 schrieb Andrew Dunstan: > I agree. I remain of the opinion that this is not a problem than can be > solved purely within the bounds of postgres. Well, the SSL patch I showed certainly solves the problem. (I am not saying it is the best possible solution.) Of course there also need to be prudent users, but that is the case for any security system. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
Am Donnerstag, 17. Januar 2008 schrieb Bruce Momjian: > It creates a lock file that is the same name as the socket file that a > default-configured client would use, so it prevents a spoofed socket > from being created. A counter-spoofing solution must be implemented in the client. No moving around of files by the server will ever solve the problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [PATCHES] [HACKERS] SSL over Unix-domain sockets
On Thu, 17 Jan 2008, Tom Lane wrote: BTW, is a symlink's atime changed by accessing it? It seems so in the cases I've tried or researched, but it's complicated. After burning through a bunch of time looking into this I wanted to drop some notes so nobody else has to wander down the specific dead-ends I just followed. I figured I'd just run some experiments to figure this out for my Linux system, but that didn't go so well. The process of running anything that shows the atime: ls -l --time=atime ls -lu stat actually updates the atime to right now along the way. I hacked up something with perl that directly calls lstat() and it did the same thing. Mystified, I found this thread suggesting the same thing is true on Mac OS X: http://lists.apple.com/archives/darwin-kernel/2006/Dec/msg00054.html The point made in there is that how symlinks are encoded varies not just from OS to OS but from filesystem to filesystem, and that encoding changes how things like atime work. On Linux with ext2, I found this note: "Symbolic links are also filesystem objects with inodes. They deserve special mention because the data for them is stored within the inode itself if the symlink is less than 60 bytes long. It uses the fields which would normally be used to store the pointers to data blocks." So what I think is happening is: the process of doing anything at all with a Linux symlink references the inode that has the link. That updates the atime on that inode. But since there's no actual data underneath that lookup in cases where the link is less than 60 bytes, the inode atime is the link atime, so that just updated the link's atime to right now as well. I have no idea how any tmp cleaner could ever find a short symlink it can delete if I'm understanding this correctly. I left behind the link I was just playing with and I'll see if I can get tmpwatch to eat it tomorrow, that seems like the most appropriate test here. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 6: explain analyze is your friend
