Re: pg_hba.conf: samehost and samenet - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pg_hba.conf: samehost and samenet
Date
Msg-id 9837222c0908140142n210021c1tf9ed12d826c1026a@mail.gmail.com
Whole thread Raw
In response to pg_hba.conf: samehost and samenet  (Stef Walter <stef-list@memberwebs.com>)
Responses Re: pg_hba.conf: samehost and samenet  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Aug 14, 2009 at 00:50, Stef Walter<stef-list@memberwebs.com> wrote:
> I love using postgresql, and have for a long time. I'm involved with
> almost a hundred postgresql installs. But this is the first time I've
> gotten into the code.
>
> Renumbering networks happens often, and will happen more frequently as
> IPv4 space runs low. The IP based restrictions in pg_hba.conf is one of
> the places where renumbering can break running installs. In addition
> when postgresql is run in BSD jails, 127.0.0.1 is not available for use
> in pg_hba.conf.
>
> It would be great if, in the cidr-address field of pg_hba.conf, we could
> specify "samehost" and "samenet". These special values use the local
> hosts network interface addresses. "samehost" allows an IP assigned to
> the local machine. "samenet" allows any host on the subnets connected to
> the local machine.
>
> This is similar to the "sameuser" value that's allowed in the database
> field.
>
> A change like this would enable admins like myself to distribute
> postgresql with something like this in the default pg_hba.conf file:
>
> host      all     all   samenet         md5
> hostssl   all     all   0.0.0.0/0       md5


Seems like a reasonable feature - especially the samehost part.


> I've attached an initial patch which implements "samehost" and
> "samenet". The patch looks more invasive than it really is, due to
> necessary indentation change (ie: a if block), and moving some code into
> a separate function.

A couple of comments on the patch:

* In general, don't include configure in the patch. Just configure.in.
Makes it easier to read, and configure is normally built by the
committer anyway.

* How portable is this? For starters is clearly doesn't do Windows,
which would need to be investigated for similar functionality, but how
many others support getifaddr()? From what I can tell it's not in
POSIX, at least.

* The checks for "not supported" should happen at parsing time, not at runtime.

* It needs to include documentation changes


I haven't looked at the guts of the patch yet, those are just a couple
of first questions.


> Thanks for your time. How can I help get a feature like this into
> postgresql?

Please add it to the open commitfest
(https://commitfest.postgresql.org/action/commitfest_view/open). This
will cause it to be reviewed during the next commitfest, and then you
just need to be around to answer any questions that reviewers come up
with :-)


-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Re: DECLARE doesn't set/reset sqlca after DECLARE cursor
Next
From: Oleg Bartunov
Date:
Subject: Re: Filtering dictionaries support and unaccent dictionary