rm -rf in initlocation violates Rule of Least Surprise

From: "Clifford T(dot) Matthews" <ctm(at)ardi(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: rm -rf in initlocation violates Rule of Least Surprise
Date: 2003-10-25 02:59:24
Message-ID: 16281.59148.51028.147610@newbie.ardi.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Using initlocation from postgresql 7.3.4 I managed to blow away some
important data tonight due to "exit_nicely"'s "rm -rf". Specifically
the system where I have postgresql installed on has a small /usr
partition, so the default location for databases is insufficient to
host one of the databases I need to load. After reading the man page
for createdb and initlocation I ran initlocation on the base of a
larger filesystem, e.g.

initlocation -D /slm/big

I didn't actually own that directory, so initlocation couldn't chmod
go-rwx it. Unbeknownst to me, initlocation proceeded to rm -rf that
directory. The directory remained, but since I had group write
permission on the directory, some files that I didn't own (that I
didn't even know were there) got killed. Nothing in the documentation
I read hinted that such a thing was going to happen.

If it's likely to be accepted, I'll make these changes to initlocation
and submit a patch:

by default, check to see that the user who is running is the owner
of the normal PGDATA directory, rather than check to see that he's
not root

In the case of failure, only delete and undo the things that
initlocation has already done

I don't read the pgsql-bugs mailing list, so you'll need to cc me (or
e-mail me off the list) to let me know that such a patch is likely to
be accepted.

Best regards,

Cliff Matthews <ctm(at)ardi(dot)com>

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Grillet 2003-10-25 20:32:36 Numeric casts in locale en_GB on FreeBSD 4.7
Previous Message Bruce Momjian 2003-10-24 20:59:40 Re: PostgreSQL Patch: Test-and-set routine for HP-UX (IA-64)