Thread: DHCP and pg_hba.conf
This is my first day here. I'm writing a HowTo for a GPL'ed accounting system (Kontor) that uses PostgreSQL. I don't use DHCP (Dynamic Host Configuration Protocol). Those that do know the client IP address is assigned dynamically. That being the case, how does one set up access / security in the pg_hba.conf file (since it requires ip addresses)? I'm sure I overlooked / don't understand a major concept about DHCP. Can anyone help or point me in the right direction? Thank you. -Ron
* Ron Atkins <theotiwii@earthlink.net> [000306 12:22] wrote: > This is my first day here. I'm writing a HowTo for a GPL'ed accounting > system (Kontor) that uses PostgreSQL. > > I don't use DHCP (Dynamic Host Configuration Protocol). Those > that do know the client IP address is assigned dynamically. > > That being the case, how does one set up access / security in the > pg_hba.conf file (since it requires ip addresses)? > > I'm sure I overlooked / don't understand a major concept about DHCP. > > Can anyone help or point me in the right direction? > > Thank you. One trick would be add the subnets/ips into the conf file and make sure DHCP only gives out IP addresses from those subnets to those clients that are authorized. -Alfred
Alfred Perlstein wrote: > One trick would be add the subnets/ips into the conf file and make > sure DHCP only gives out IP addresses from those subnets to those > clients that are authorized. That is an idea. Isn't PostgreSQL limited by not utilizing some type of name resolution? Am I looking for a work around because name resolution has yet to be added, or is my question flawed? Thank you for your help and your response Alfred -Ron PS: Another user posted this answer off list, I append our conversation: > use localhost (127.0.0.1). This begs the following two questions: Question 1: If the PostgreSQL client and server do not reside on the same host, is "localhost" just a kludge to indicate dynamic addressed clients? Question 2: On a single system used as host and server, RMI (Remote Method Invocation) refuses localhost as a parameter, it requires the hostname or the IP address. Naturally PostgreSQL does what it wants, have you had the occasion to confirm localhost works?
Ron Atkins wrote: > This is my first day here. I'm writing a HowTo for a GPL'ed accounting > system (Kontor) that uses PostgreSQL. > I don't use DHCP (Dynamic Host Configuration Protocol). Those > that do know the client IP address is assigned dynamically. ...based on a few things. It can assign random from a pool. It can assign *specific* IP numbers to *specific* machines, as well. > That being the case, how does one set up access / security in the > pg_hba.conf file (since it requires ip addresses)? I havn't poked into hba.conf for a while, but DHCP is about dynamic *assignment*. It doesn't mean that machines can't always get the same IP, it just means that the IP is dynamically assigned to the host... *However*, if you look at the last example on this page: http://www.postgresql.org/docs/admin/security.htm#AEN1240 You can see that an entire block can be considered valid, trusted, or non-trusted. This means your can set an entire DHCP pool range to be trusted, if you wish. -Ronabop -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary...and winmodems suck big smelly rocks.
Ron Atkins wrote: > Isn't PostgreSQL limited by not utilizing some type of name resolution? DNS refers to address first, _then_ the name. No IP, no name, so it works the other way around... I guess adding it might make life easier for those adding single hosts, but since you can't add an entire range of hosts too easily by one name, and have it map back to IP packets, running security off of names would be much slower, as each session had to waste time on name lookups rather than just mapping to the address. A note on DNS: It's a user feature. It's there to make humans understand where packets are going. It has _nothing_ to do with where they actually go, or where they actually come from. > Am > I looking for a work around because name resolution has yet to be added, or > is my question flawed? If you are using standard internet DNS, you can't have a name without a static IP to point that name to. So the IP comes first, name is *dependant* on IP. -Boppers -- Brought to you from boop!, the dual boot Linux/Win95 Compaq Presario 1625 laptop, currently running RedHat 6.1. Your bopping may vary...and winmodems suck big smelly rocks.
Ron Chmara <ron@opus1.com> writes:
> running security off of names would be much slower, as each session had
> to waste time on name lookups rather than just mapping to the address.
Another note: Many programs which implement host-based ACLs seem to
just do a reverse lookup on the IP of the client. This is a very bad
idea (IMHO):
Let's say you're running a database that allows connections from
yourdomain.com, and I want to break in. If I control a nameserver
that's authoritative for my own IP address range, I can break in
simply by creating a PTR record for my machine which points to
"something.yourdomain.com."
The right way to implement host-based ACLs is to do a double lookup;
resolve the IP to a hostname, and then verify that the hostname
resolves back to the original IP.
With such a system in place in PostgreSQL, it might be more reasonable
to allow something like "%.accounting.mycompany.com" in an ACL.
Chris
--
---------------------------------------------------- cjones@rightnowtech.com
Chris Jones
System Administrator, Right Now Technologies, Inc.
"Is this going to be a stand-up programming session, sir, or another bug hunt?"
Ron Chmara wrote: > running security off of names would be much slower, as each session had > to waste time on name lookups rather than just mapping to the address. I'm starting to understand the issues involved. Thank you for explaining that. Your other reply and that of Alfred Perlstein become quite reasonable under those circumstances. I will explain in the HowTo the options as they were explained by you to me. Thank you. A disclaimer. I previously stated: RMI (Remote Method Invocation) refuses localhost as a parameter, it requires the hostname or the IP address. Researching "localhost" settings, I now know this is incorrect. On the odd chance this configuration is required by anyone reading this, mail me and I will forward the process. Thank you again. As times goes by, I hope to add more then I take. -Ron