... >> 2. What do we think about the SQL command to be. Would it be like the >> following or another syntax. >> >> GRANT >> CONNECTION [LOCAL | HOST | HOSTSSL | HOSTNOSSL ] >> ON [ ALL | mydatabase1 ] >> TO [ ALL | user1,user2,user3 ] >> FROM 127.0.0.1/32 >> METHOD [ TRUST | REJECT | MD5 ...... ] > > Apart from the complaint that this makes no attempt to take care of the > fact that entires in pg_hba.conf are order sensetive. Where is that > found in this syntax? What about pg_ident.conf?
there is actually no proof of the current order depency is really a good idea. Other access lists work without that constraint. >> 3. Could someone clarify the design decisions regarding pg_hba.conf >> file? Why was it done the why it is today? (Tom? Bruce?) > > Not sure if there was a design. It was created at some point and > evolved. Maybe now we can do a real design? No need to continue on the wrong path (if it is wrong). > Now, to just suggest something I've been thinking of. Maybe a way of > thinking about it is similar to firewall chains in linux. You keep > pg_hba.conf but allow it to refer to a new auth type "chain blah". Then not that "chains" are the only and the best solution to firewall rules out there :-) > you layer your above grant syntax into those chains. This allow people > to switch between different auth methods quickly by switching files, > while allowing people who want to do everything in the database can do > so too. Even with in database rules only you can do the switches - you remove all entries, keeping your current connection and then bring them back when you are ready. Just a matter of some SQL commands in a script. Kind regards Tino ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq