Agent M wrote:
Sorry, but you misunderstand- nowhere am I interested in the role's
password. My previous suggestion was to add a password to set session
authorization itself so that if the authorization were to be reset, it
would need to be done with that password; the password itself could be
machine-generated. It it would merely allow a secure sandbox to be
established between:
SET SESSION AUTHORIZATION somerole WITH PASSWORD 'abc';
--arbitrary SQL run as somerole
RESET SESSION AUTHORIZATION; --fails- requires password
RESET SESSION AUTHORIZATION WITH PASSWORD 'pass'; --fails
RESET SESSION AUTHORIZATION WITH PASSWORD 'abc'; --succeeds- we are done
with this role
Why don't you just use "SET SESSION AUTHORIZATION somerole", and then scan
the to-be-executel sql scripts for any occurence of "reset session
authorization",
and ignore the script it matches.
Of course you'd need to be a bit carefull to catch all syntactially valid
variations (like ReSeT SeSsIoN AuToRiZaTiOn), but that should be doable.
If you design your "matched" carefully, the only way to defeat that protection
would be to wrap the "reset session authorization" command in a function, which
I believe is not possible.
greetings, Florian Pflug
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
