Docs bug: SET ROLE docs should "see also: DISCARD ALL"

From: Craig Ringer <ringerc(at)ringerc(dot)id(dot)au>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Docs bug: SET ROLE docs should "see also: DISCARD ALL"
Date: 2012-10-04 02:56:06
Message-ID: 506CFAC6.2020600@ringerc.id.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi folks

There's no mention anywhere in `SET ROLE` of the ability of `DISCARD
ALL` to reset the role to default. Ditto `SET SESSION AUTHORIZATION`.

That's pretty important, since an app that wants to allow arbitrary SQL
to be executed as an assumed user identity might be guarding against
"RESET ROLE", "SET ROLE", etc statements but not know to watch for
"DISCARD". Sure, it's a bad idea to accept arbitrary SQL from a client,
and filtering it is never going to be perfect, but it's clear when
looking at things like discussion of RESET ROLE in SECURITY DEFINER
functions that this is something people do and is a concern.

BTW, it'd be *really* nice if there were a way to:

SET ROLE some_role RESET_COOKIE 'random-garbage';

that prevented RESET ROLE without supplying a RESET_COOKIE. Ditto again
for `SET SESSION AUTHORIZATION`.

For that matter it'd be helpful even to have a "NORESET" option that
made it like a priv drop, where DISCARD ALL, RESET ROLE, RESET SESSION
AUTHORIZATION etc after a SET ROLE somebody NORESET or SET SESSION
AUTHORIZATION somebody NORESET just did nothing.

--
Craig Ringer

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-10-04 03:07:51 Re: Question on "box @> point" using GiST index on boxes
Previous Message Tom Lane 2012-10-04 02:51:29 Re: Support for REINDEX CONCURRENTLY