The pg_hba.conf file - Mailing list pgsql-novice

From
Subject The pg_hba.conf file
Date
Msg-id Pine.A41.3.95.1021218223032.21626A-100000@fn2.freenet.edmonton.ab.ca
Whole thread Raw
Responses Re: The pg_hba.conf file
List pgsql-novice
Hi all,
  I recently upgraded to 7.3 on my Debian system, and found that
the format of this file has changed slightly.  So, since I need to
revisit the file, I figured I might as well send a longish note.

  I've never found host based access with Postgres to be
intuitive.  Maybe this is good, maybe bad.  I think other people
have problems with it as well.  I'm picking some examples from
stuff on my system (which is Debian), not to complain about them,
just as a source of examples.

1 ----------------------------------
First off, we have 3 different kinds of records: local, host and hostssl.

local    DBASE  USER                   METHOD  [OPTION]
host     DBASE  USER  IP_ADD  IP_MASK  METHOD  [OPTION]
hostssl  DBASE  USER  IP_ADD  IP_MASK  METHOD  [OPTION]

To me, it would seem "more pleasing" if the local record looked
a little more like the host and hostssl records, with something
there for the IP_ADD and IP_MASK fields.  Ideas I've had are:
"x.x.x.x", "NotApplicable" and "NA".  Something.  That way field
#0 is always the access method, field #1 is the DBASE name, field
#2 is the user name, ....  For local access, the 4th and 5th fields
would just be ignored.

It's an idea anyway.  I can't say I've seen anything  on the mailing
list talking about the assymmetry of local versus host/hostssl.

2 --------------------------------
Next, authenication involving ident.  From what I've been told by
more security concious people than myself, that ident can not be
trusted off of the local machine.  And, I've seen some ident daemons
which apparently can be configured to lie.  Which leads me to ask
the question, is ident trustworthy for local connections?  Certainly
these lying ident daemons could lie on a network connection, but
are they also involved in local (socket) connections?  Or is it
the kernel which is responding with the UID of the other end of
the socket?

3 -----------------------------
It's not unusual for maintainence to be done via cron jobs on
the database(s).  I gather this probably needs to be done by
the postgres user in all cases (are there exceptions?).  Debian
currently suggests in do.maintainence
 local  all      ident sameuser
(this looks like a pre 7.3 line which should read?)
 local  all  all     ident sameuser

Another "superuser" type access to PostgreSQL is
PHPPGAdmin.  From the Debian README, I have a choice of
 local  all      password
and
 host  all  127.0.0.1  255.255.255.255  crypt
(Oh, neither line looks like a 7.3 line.)

Webmin?  I can't find any file under /usr/share/doc/webmin*
which talks about pg_hba.conf settings.  Surely it makes
assumptions on what is in pg_hba.conf for it to work.

To me, it sure looks like to use PHP PGAdmin I need to
make sure that
  $cfgServers[1]['local'] = false
so that I access PostgreSQL via the host 127.0.01 as I
can't think of any method which allows the do.maintainence
cron job to connect using ident and PGAdmin to connect using
password.  They are both working with all databases as the postgres
user, so the first line used (either ident or password) would get used
and the other ignored.

Anyway, above I have 2 differing needs just from a setup point
of view.  I also may have other local needs.  I don't have any
problems with the idea of local connections from the UNIX postgres
user being trusted to all databases.  But why do these
recommendations have such huge scope?  It's not unusual for a user
to have a database with the same name as his/her UID, so I guess
we could allow that by policy.  Pg_hba.conf allows for access to
databases owned by some group.  And I have some programs which do
not involve a UNIX UID, and would like to allow access via
passwords of some kind.  Wouldn't something like:
 local  all       postgres       ident sameuser
 local  sameuser  all            ident sameuser
 local  samegroup all            ident sameuser
 local  @l_other  all            md5
be a good, generic setup for pg_hba.conf involving local
connections?  (Where the file l_other, contained the names of
other local databases I wanted to let people access by password.)

3.1 ---------------------------------------------
In the above local ... example, I suspect having "ident sameuser"
as the authentication allowing access to the database "sameuser"
restricts completely, but the "all" wildcard for the user seems out
of place.  Something like:
 local sameuser sameuser  ident sameuser
seems to better describe the situation, that I only want these
connections by UNIX UIDs to databases with the same name as
the UNIX UID.

And I am only guessing that the line involving samegroup
works as written.

4 -------------------------------------------------
It's not unusual to see sample pg_hba.conf files, which have
a
  host  all all  0.0.0.0   0.0.0.0   reject
line at the end.  Should a person have similar lines for hostssl
and local connections?  I.e.:
 local  all   all            reject
 host  all  all   0.0.0.0 0.0.0.0  reject
 hostssl all  all  0.0.0.0 0.0.0.0  reject

Sorry for the too-longish note.  But, I'm a little unsure about
this, and I think others are as well.  Maybe it's just me.  :-)

Gord
--
Matter Realisations     http://www.materialisations.com/
Gordon Haverland, B.Sc. M.Eng. President
101  9504 182 St. NW    Edmonton, AB, CA  T5T 3A7
780/481-8019            ghaverla @ freenet.edmonton.ab.ca
780/993-1274 (alt.)



pgsql-novice by date:

Previous
From: Ron Johnson
Date:
Subject: Re: skipping records with duplicate key during COPY
Next
From: Bruno Wolff III
Date:
Subject: Re: The pg_hba.conf file