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