Re: One Role, Two Passwords

From: Daniel Farina <drfarina(at)acm(dot)org>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: One Role, Two Passwords
Date: 2011-01-23 22:04:53
Message-ID: AANLkTi=a-fH8DPTtmk5GrOdzZx8VStAWhEwLg9m13HrQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 20, 2011 at 6:19 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> Errr, well, ok, this is curious.
>
> gis=> alter user sfrost set role gis;
> ALTER ROLE
> gis=> ^D\q
> beren:/home/sfrost> psql --cluster 8.4/main -d gis
> psql (8.4.5)
> Type "help" for help.
>
> gis=> show role;
>  role
> ------
>  gis

So far, I think this does exactly what you think it would...

This is how I think a mostly-transparent one-role-two-password (ish)
system would look like using this property, using a group, as Tom
suggested:

-- Note: This role does not have LOGIN set
CREATE ROLE public_facing_name;

-- The first set of credentials
CREATE ROLE first_arbitrary_name IN ROLE public_facing_name LOGIN
PASSWORD 'first_secret';
ALTER ROLE first_arbitrary_name SET ROLE public_facing_name;

-- The second set of credentials
CREATE ROLE second_arbitrary_string IN ROLE public_facing_neme LOGIN
PASSWORD 'second_secret';
ALTER ROLE second_arbitrary_name SET ROLE public_facing_name;

When one logs in as one_arbitrary_name or second_arbitrary_name, all
CREATE statements -- and indeed, all privilege checks -- will take
place against public_facing_name. No objects should ever get created
under the roles "first_arbitrary_name" or "second_arbitrary_name," and
no ownership ever assigned to them, unless the client runs SET ROLE to
un-do what was done. This would be annoying (when dropping sets of
credentials, or when ownership-specific privileges apply to one set of
credentials but not the other) but may not occur much at large.

Thoughts?

--
fdr

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-01-23 22:10:43 Re: ALTER TABLE ... ADD FOREIGN KEY ... NOT ENFORCED
Previous Message Joel Jacobson 2011-01-23 21:24:43 Re: Bug in pg_describe_object, patch v2