From: | Agent M <agentm(at)themactionfaction(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: sudo-like behavior |
Date: | 2006-04-23 19:07:23 |
Message-ID: | 944eb502338b550a5c9a840beb3da119@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Apr 22, 2006, at 1:13 PM, Florian G. Pflug wrote:
>
> 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.
Unfortunately, it is possible:
agentm=# CREATE OR REPLACE FUNCTION testacl() RETURNS void AS $$ RESET
SESSION AUTHORIZATION; $$ LANGUAGE SQL;
CREATE FUNCTION
agentm=# select current_user;
current_user
--------------
agentm
(1 row)
agentm=# set session authorization test;
SET
agentm=> select current_user;
current_user
--------------
test
(1 row)
agentm=> select testacl();
testacl
---------
(1 row)
agentm=# select current_user;
current_user
--------------
agentm
(1 row)
So, currently, there is a security limitation in postgresql which
effectively prohibits switching roles midstream unless you can control
the statements of that role, i.e. there is no sandbox feature
available. (Such a feature would also be great for pooled connections,
but that has already been discussed as well.)
-M
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm(at)themactionfaction(dot)com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
From | Date | Subject | |
---|---|---|---|
Next Message | David F. Johnson | 2006-04-24 01:33:40 | "save history" problem |
Previous Message | Florian G. Pflug | 2006-04-23 18:29:12 | Re: Automatically assuming a specific role after connecting |