Re: One Role, Two Passwords

From: Daniel Farina <drfarina(at)acm(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: One Role, Two Passwords
Date: 2011-01-21 00:23:43
Message-ID: AANLkTingwWoLMi8VoC9C=1af5wA9nSStKQoAR=bUQZd+@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 20, 2011 at 3:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <drfarina(at)acm(dot)org> writes:
>> I wanted to test the waters on how receptive people might be to an
>> extension that would allow Postgres to support two passwords for a
>> given role.
>
> Not very.  Why don't you just put two roles in the same group?

How does this work with newly created objects? Is there a way to have
them default objects to a different owner, the parent of the two
roles?

It is highly desirable that no ALTER <OBJECT> statements should need
issuing after the password transition is complete. As-is, though, I
don't understand how that would be possible.

It would also be nice to be able to change a password without changing
the role name. In the case of password rotation, the goal would be to
drop the old password after all clients have had reasonable chance to
get an update. One could work around by generating new
username+password pairs constantly, but there are conveniences to
having a stable public-identifier for a role in addition to a private
secret used to authenticate it (or, as is the case with this proposal,
more than one acceptable private secrets). Changing the username all
the time to facilitiate this basically renders it part of a unstable,
two-part secret key, and the job of having a stable, public identifier
is pushed up the application stack.

--
fdr

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-01-21 00:28:25 Re: SSI and Hot Standby
Previous Message Bruce Momjian 2011-01-21 00:11:26 JSON data type status?