Re: Post Install / Secure PostgreSQL

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Carlos Mennens <carlos(dot)mennens(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Post Install / Secure PostgreSQL
Date: 2010-09-14 01:58:56
Message-ID: 4C8ED6E0.3020900@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 14/09/2010 1:57 AM, Tom Lane wrote:
> I'd suggest creating "carlos" as either a plain user or a CREATEROLE
> user depending on whether you think you're likely to be adding/deleting
> plain users regularly.

I'd second that.

When I install a new instance of PostgreSQL, I usually set up a "craig"
user to match my Linux login ID. This user has CREATEDB and CREATEROLE
rights, but is not a superuser.

This account will be used automatically by psql unless I override it,
because psql defaults to local unix socket logins with the same
postgresql username as the unix username. pg_hba.conf by default permits
local unix users to use the postgresql user account with the same user
name as their unix account. So I can just run "psql databasename" to
connect to any database that I've granted access rights to "craig" for.

I then usecreate a "craig" database as a test area / playpen. This will
be connected to by default if I run psql without any arguments.

So:

craig$ sudo -u postgres psql
postgres=> CREATE USER craig WITH PASSWORD 'somepassword'
CREATEDB CREATEROLE;
postgres=> CREATE DATABASE craig WITH OWNER craig;
postgres=> \q

Now I can connect to my new default database with a simple "psql". For
any real work I make new databases, but the "craig" database is handy
for general testing and playing around. I generally revoke public
connect rights on those databases, permitting only specific users to
connect even if they're authenticated and allowed access to other databases.

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2010-09-14 02:01:51 Re: Any plans to expose publicly (via stored proc) relation_needs_vacanalyze, or some flavour of do_autovacuum?
Previous Message Yaroslav Tykhiy 2010-09-14 00:37:27 Re: Query plan choice issue