Re: Any way to have CREATEUSER privs without having all privs? - Mailing list pgsql-general

From Bruno Wolff III
Subject Re: Any way to have CREATEUSER privs without having all privs?
Date
Msg-id 20040106133004.GA23682@wolff.to
Whole thread Raw
In response to Any way to have CREATEUSER privs without having all privs?  ("ezra epstein" <ee_newsgroup_post@prajnait.com>)
List pgsql-general
On Fri, Jan 02, 2004 at 07:18:45 -0800,
  ezra epstein <ee_newsgroup_post@prajnait.com> wrote:
> I've got a user with CREATEUSER privs.  I've not granted that user and DB
> specific privs but it can do what it will with non-public schemas...  Is
> there a user that can do SET SESSION AUTHORIZATION but does not have privs
> otherwise?
>
> Basically I want a login user that can then set session auth... to any other
> user but otherwise has no privs.  (Having createuser is acceptable.)  I'm
> looking into a way to give connection pooled access to a web site
> (connections must have the same user/pw info to be pooled) but to then
> enforce DB-level security.  I do not want the account that the web container
> uses to access the db to have any db-level privs.

If the web server and the DB server are the same machine or the web server
machine runs an identd service that you can trust, then you can do what you
want using ident authentication. The ident map file doesn't have an "all"
keyword, so you will need to update it as you add users.

> (I.e., rather than the Unix "root" account, something more like VMS (now
> Windows NT) user privs. VMS users had a "set priv" privilege which, of
> course, could indirectly give the holder of that priv any other priv.  But
> only indirectly.  It has some benefits.)

VMS' set priv feature wasn't well designed (at least in early versions of VMS).
You didn't need to reauthenticate to elevate your privileges, so you still
had to be VERY careful when running other people's programs as they would
have access to your elevated privileges.

pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: pg_dump and client_encoding
Next
From: David Garamond
Date:
Subject: Re: release notes/Appendix E in documentation