A while back, one of my younger co-workers asked me why Amazon RDS doesn't support a real Postgres superuser. I replied by showing him this:
create table passwords (entry text); copy passwords from '/etc/passwd';
He ran off to try running the same code against our production database
using Splunk (I didn't ask; I didn't want to know, and still don't). But
this example, while dramatic, doesn't really answer the question;
/etc/passwd
is intended to be read by anyone.
What I should have done was show him this example (warning: don't try this at home unless you enjoy restoring from backups!):
copy passwords to '/usr/local/pgsql/data/postgresql.conf';
You may be wondering — like my colleague was — why Postgres would have such a huge security hole. And the answer is that it's not: only superusers can copy to or from files. If an ordinary user tries either of these statements, this is the response:
ERROR: must be superuser to COPY to or from a file HINT: Anyone can COPY to stdout or from stdin. psql's \copy command also works for anyone.
The real security hole was that we were using the superuser as our standard login, because it made managing the database easier. And while the ability to overwrite files is one reason not to do that, there's a bigger one: we were one mis-qualified table name away from corrupting the data in the database, because the superuser also bypasses any checks on schema or database permissions.
No comments:
Post a Comment