Thread: pg_dump schema search_path; selectSourceSchema()
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™
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-260-0005
"Thomas F. O'Connell" <tfo@sitening.com> writes:
> Our first attempt to get things working was to remove all calls to
> selectSourceSchema. Clearly, this is playing with fire,
No, it's breaking it entirely; and so would your proposed change.
The reason for the restrictive search path is to ensure that references
to stuff in other schemas is dumped with fully qualified names.
Anything you add to the search path creates added risk of incorrect
recreation of object definitions at reload.
If the added schema contains *only* your replacement pg_database and
pg_user views, the risk might be relatively small --- but I trust you
can see that in general such a thing would be a bug not a feature.
On the whole I continue to regard this project as a dead end. It will
be a whole lot simpler and more reliable to give each user his own
postmaster, if you want airtight separation between users.
regards, tom lane