We should prevent pg_resetxlog from being run as root: it writes new
files to $PGDATA, so running the tool as root will result in those files
being owned by root, which makes the data directory unusable.
Attached is a trivial patch that makes this change for Unix. I suppose a
similar fix is needed for Win32? If so, pgwin32_is_admin() would be the
natural routine to call, but that is currently in src/backend/port -- we
would need to move it to src/port, probably. Comments?
-Neil
Index: src/bin/pg_resetxlog/pg_resetxlog.c
===================================================================
RCS file: /var/lib/cvs/pgsql/src/bin/pg_resetxlog/pg_resetxlog.c,v
retrieving revision 1.25
diff -c -r1.25 pg_resetxlog.c
*** src/bin/pg_resetxlog/pg_resetxlog.c 17 Nov 2004 21:37:47 -0000 1.25
--- src/bin/pg_resetxlog/pg_resetxlog.c 9 Dec 2004 07:03:20 -0000
***************
*** 181,186 ****
--- 181,200 ----
snprintf(ControlFilePath, MAXPGPATH, "%s/global/pg_control", DataDir);
/*
+ * Don't allow pg_resetxlog to be run as root, to avoid
+ * overwriting the ownership of files in the data directory. We
+ * need only check for root -- any other user won't have
+ * sufficient permissions to modify files in the data directory.
+ */
+ if (geteuid() == 0)
+ {
+ fprintf(stderr, _("%s: cannot be run as \"root\"\n"), progname);
+ fprintf(stderr, _("You must run pg_resetxlog "
+ "as the PostgreSQL superuser.\n"));
+ exit(1);
+ }
+
+ /*
* Check for a postmaster lock file --- if there is one, refuse to
* proceed, on grounds we might be interfering with a live
* installation.
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
