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: