Re: sudo-like behavior

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
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬

In response to

Browse pgsql-general by date

  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