Re: security_definer_search_path GUC
Pavel Stehule <pavel.stehule@gmail.com>
From: Pavel Stehule <pavel.stehule@gmail.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Marko Tiikkaja <marko@joh.to>, Joel Jacobson <joel@compiler.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Chapman Flack <chap@anastigmatix.net>
Date: 2021-06-03T16:38:23Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Create a new GUC variable search_path to control the namespace search
- 838fe25a9532 7.3.1 cited
čt 3. 6. 2021 v 18:30 odesílatel Mark Dilger <mark.dilger@enterprisedb.com> napsal: > > > > On Jun 3, 2021, at 9:03 AM, Pavel Stehule <pavel.stehule@gmail.com> > wrote: > > > > I agree so some possibility of locking search_path or possibility to > control who and when can change it can increase security. This should be a > core feature. It's maybe more generic issue - same functionality can be > required for work_mem setting, maybe max_paralel_workers_per_gather, and > other GUC > > Chapman already suggested a mechanism in [1] to allow chaining together > additional validators for GUCs. > > When setting search_path, the check_search_path(char **newval, void > **extra, GucSource source) function is invoked. As I understand Chapman's > proposal, additional validators could be added to any GUC. You could > implement search_path restrictions by defining additional validators that > enforce whatever restriction you like. > This design looks good for extensions, but I am not sure if it is good for users. Some declarative way without necessity to programming or install some extension can be nice. Pavel > Marko, does his idea sound workable for your needs? I understood your > original proposal as only restricting the value of search_path within > security definer functions. This idea would allow you to restrict it > everywhere, and not tailored to just that context. > > [1] > https://www.postgresql.org/message-id/608C9A81.3020006@anastigmatix.net > > — > Mark Dilger > EnterpriseDB: http://www.enterprisedb.com > The Enterprise PostgreSQL Company > > > >