pg_dump schema search_path; selectSourceSchema() - Mailing list pgsql-hackers

From Thomas F. O'Connell
Subject pg_dump schema search_path; selectSourceSchema()
Date
Msg-id 60E67733-D590-4F2A-8A43-76E341D9C8DE@sitening.com
Whole thread Raw
Responses Re: pg_dump schema search_path; selectSourceSchema()  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
As I mentioned in the last post to a thread in general detailing some of the hurdles of attempting to set up PostgreSQL virtual hosting, we've had to hack pg_dump to achieve the behavior that we want.

The modifications we made call into question (for us, anyway) a few design decisions in PostgreSQL utilities, and we're wondering if our modification has unintentional ramifications or if, as an option, it's something that the hackers see value in.

The main issue for us is that we are relying on search_path to cause phpPgAdmin and pg_dump to find restricted views into the system catalogs. selectSourceSchema as written breaks our expectations when it is called with pg_catalog as a single argument.

Our first attempt to get things working was to remove all calls to selectSourceSchema. Clearly, this is playing with fire, and I'll admit to not understanding all the references to schemas other than the explicit pg_catalog references.

What we're currently thinking of doing is adding a flag like --search-path-prefix that would let us prepend any path requirements we have to the built-in calls to selectSourceSchema(). So that if we're putting our user-restricted system catalog views in public (as we're currently doing) or a custom schema (which would be my ideal preference), we can prepend that to the search_path, and pg_dump will behave as expected when run by a user in a hardened environment as long as users haven't done anything foolish. I'm just wondering whether such a patch seems sane and adds value from the perspective of hackers. Are we overlooking any scenarios in which pg_dump specifically requires a more restrictive search_path in order to behave properly?

From a bigger picture standpoint, this is mostly necessary because there's no way to configure PostgreSQL to restrict access to the system catalogs in any meaningful way. I'm not really sure how to search for discussions on this topic in the archives, and I'm also not sure whether the forthcoming roles features will go any way toward eliminating the need for such behavior.

--

Thomas F. O'Connell

Co-Founder, Information Architect

Sitening, LLC


Strategic Open Source: Open Your i™


http://www.sitening.com/

110 30th Avenue North, Suite 6

Nashville, TN 37203-6320

615-260-0005


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Must be owner to truncate?
Next
From: Andrew Dunstan
Date:
Subject: multibyte regression tests