From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Agent M <agentm(at)themactionfaction(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: sudo-like behavior |
Date: | 2006-04-22 18:22:22 |
Message-ID: | 444A745E.2040403@phlo.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>
>>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.
>
> What would probably be better is a way to do SET SESSION AUTHORIZATION
> and then abandon the underlying superuser privilege, thereby absolutely
> guaranteeing that the session can't do anything the selected userid
> shouldn't be able to do. You'd have to start a new session for each
> cronjob, but that would be a Really Good Idea anyway, given the lack of
> any way to fully restore a session to default state.
My "solution" (or hack ;-) ) was meant to work with current versions of postgres..
Of course, a command like "set session authorization <user> final" or such would be
a better way - maybe something for 8.2? ;-))
mfg, Florian Pflug
From | Date | Subject | |
---|---|---|---|
Next Message | Florian G. Pflug | 2006-04-22 18:24:43 | Automatically assuming a specific role after connecting to pg |
Previous Message | Tom Lane | 2006-04-22 18:08:31 | Re: sudo-like behavior |