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])

Reply via email to