Thanks Christoph and Justin. To follow up, I agree with:
But I tend to think we should add schema quals, since that's what postgres > does. > I think it is definitely preferable that PyGreSQL should add schema qualifications to all operators and system tables. Please let me know if there are any plans for doing so. Thank you. Shoaib On Sat, Aug 24, 2019 at 2:01 PM Justin Pryzby <pry...@telsasoft.com> wrote: > On Sat, Aug 24, 2019 at 10:05:46PM +0200, Christoph Zwerschke wrote: > > Am 16.08.2019 um 19:58 schrieb Shoaib Lari: > > > I was wondering if the PyGreSQL community has any plans to address > > > PostgreSQL security vulnerability > > > > https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058:_Protect_Your_Search_Path > . > > > > Hi Shoaib, thanks for bringing this to our attention. > > Yes, thanks for mentioning it. > > > The internal query used by the type cache looks something like this: > > > > SELECT oid, typname, ... FROM pg_type WHERE oid=%s > > > > As far as I understand, to make things secure at least what concerns > > PyGreSQL, we would need to change that query to: > > > > SELECT oid, typname, ... FROM pg_catalog.pg_type > > WHERE oid OPERATOR(pg.catalog.=) %s > > Yes, I think > > > This would make the queries look more ugly and lengthy. Not sure about > the > > performance impact - maybe it would be even faster because of the > explicit > > schema name. > > I agree that they're uglier... > > > What do others think? Should we make these changes? > > But I tend to think we should add schema quals, since that's what postgres > does. > > See the commit for that CVE: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=3d2aed664ee8271fd6c721ed0aa10168cda112ea;hp=3bf05e096b9f8375e640c5d7996aa57efd7f240c > > But it looks like that convention dates back to: > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=039cb479884abc28ee494f6cf6c5e7ec26b88fc8 > > See describe.c > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/bin/psql/describe.c > > For example \d makes a half dozen queries which look like: > > [pryzbyj@database ~]$ psql ts -Ec '\d pg_class' > ********* QUERY ********** > SELECT c.oid, > n.nspname, > c.relname > FROM pg_catalog.pg_class c > LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace > WHERE c.relname OPERATOR(pg_catalog.~) '^(pg_class)$' > AND pg_catalog.pg_table_is_visible(c.oid) > ORDER BY 2, 3; > ************************** > > > Now, if someone was able to do that I think your goose has been cooked > > anyway since nearly every query will be affected. > ... > > I think in practice you need to rely on users not being able to create > > objects in the public schema, otherwise you're set for deeper troubles > > anyway, no matter how secure your API is. > > | Without adjusting the configuration or access control settings, any user > that can connect to a database can also create objects in the public schema > for that database. > > It's true that one shouldn't create untrusted DB users, but there's a > privilege > system in place and it's intended to allow users to be at least partially > segregated. If postgres/pygres and other projects don't use schema quals, > then > it's hard to imagine that a typical admin will do so. > _______________________________________________ > PyGreSQL mailing list > PyGreSQL@Vex.Net > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.vex.net_mailman_listinfo_pygresql&d=DwICAg&c=lnl9vOaLMzsy2niBC8-h_K-7QJuNJEsFrzdndhuJ3Sw&r=3cwotWBfZibARvfJ51PO7g&m=U_weQUGUrfK1RAoQWDkWcIpERzRmezLxTocyvRj1aAA&s=HuhIej92nDEgUTo99tcMK1yx9USCGBZcIC4MwgLzJRI&e= >
_______________________________________________ PyGreSQL mailing list PyGreSQL@Vex.Net https://mail.vex.net/mailman/listinfo/pygresql
