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
The password ensures that the session authorization initiator is the
only one that can terminate it as well.
-M
On Apr 20, 2006, at 10:44 PM, Tom Lane wrote:
> Agent M <agentm@themactionfaction.com> writes:
>> I really haven't provided enough details- my fault. What I want to
>> accomplish is a general-purpose timer facility for postgresql.
>
> I'm not really sure why you think it'd be a good idea for such a thing
> to operate as an unprivileged user that gets around its lack of
> privilege by storing copies of everyone else's passwords. I can think
> of several reasonable ways to design the privilege handling for a
> cron-like facility, but giving it cleartext copies of everyone's
> passwords is not one of them.
>
> regards, tom lane
>
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬