> This is definitely stressing pg_hba past its design limits --- heck, the
> name of the file isn't even appropriate anymore, if usernames are part
> of the match criteria. Rather than contorting things to maintain a
> pretense of backwards compatibility, it's time to abandon the current
> file format, change the name, and start over. (I believe there are
> traces in the code of this having been done before.) We could probably
> arrange to read and convert the existing pg_hba format if we don't see
> a new-style authentication config file out there.
>
> My first thoughts are (a) add a column outright for matching username;
> (b) for both database and username columns, allow a filename reference
> so that a bunch of names can be stored separately from the master
> authentication file. I don't much care for sticking large lists of
> names into the auth file itself.
OK, I have an idea. I was never happy with the AUTH_ARGUMENT column.
What I propose is adding an optional auth_type=val capability to the
file, so an AUTH_ARGUMENT column isn't needed. If a username column
starts with @, it is a file name containing user names. The same can be
done with the database column. Seems very backward compatible.. If you
don't use auth_argument, it is totally compatible. If you do, you need
to use the new format auth_type=val:
TYPE DATABASE IP_ADDRESS MASK AUTH_TYPE USERNAMES
local all trust fred
host all 127.0.0.1 255.255.255.255 trust @staff
host all 127.0.0.1 255.255.255.255 ident=sales jimmy
I have thought about a redesign of the file, but I can't come up with
something that is as powerful, and cleaner. Do others have ideas?
As far as missing features, I can't think of other things people have
asked for in pg_hba.conf except usernames.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
