Re: Bad permissions bug in 7.3 dump (and 7.4)?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au>
Cc: "Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bad permissions bug in 7.3 dump (and 7.4)?
Date: 2003-07-14 20:13:00
Message-ID: 13787.1058213580@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Christopher Kings-Lynne" <chriskl(at)familyhealth(dot)com(dot)au> writes:
> Has anyone looked at this problem? I have delved into the source code, but
> I can't for the life of me see where to make the change. I think there are
> actually a few possible solutions:

> * Dump all foreign key constraints as a superuser

I don't like that solution --- pg_dump should not operate on the
assumption that it has access to a superuser account, at least not
when dumping single-owner databases.

> * Prevent changing ownership of tables that have foreign keys where the new
> owner does not have REFERENCE privs for all referenced tables.
> * Grant REFERENCE to new owner when changing ownership of table.

Neither of these would really prevent the problem AFAICS, since you
could easily create the same situation by revoking the REFERENCE priv
afterwards.

The generic problem is that you can get into states where references
exist that should not be allowed under the current privilege setup.
It doesn't only affect foreign keys, either --- consider for example
a view that references a table in another schema, and suppose USAGE
rights on that other schema are revoked from the view owner.

Probably the only real solution is to implement DROP-CASCADE-like
checking when a privilege is revoked. Seems like rather a lot of
work :-(

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-07-14 20:41:41 Re: Possible psql bug
Previous Message Tom Lane 2003-07-14 20:05:57 Re: cvs version compile error on AIX 4.3.3 using xlc (long)