Re: Parsing of pg_hba.conf and authentication inconsistencies

Stephen Frost wrote:
> Magnus,
>
> * Magnus Hagander (magnus(at)hagander(dot)net) wrote:
>> I thought of another issue with this. My "grand plan" includes being
>> able to do username mapping (per pg_ident.conf) for other authentication
>> methods than ident. Specifically this would be interesting for all
>> external methods, like gssapi/sspi/kerberos/ldap. I was originally
>> planning to allow each row in pg_hba to specify it's own pg_ident.conf
>> if necessary (so you could map LDAP and GSSAPI differently, for example,
>> or map two different kerberos realms differently). To be able to load
>> these, the postmaster would need to know about them, which means it'd
>> have to parse that data out anyway.
>
> I certainly like the concept of having them be in seperate files.
>
>> The other way to do that is to simply say that all external mapping will
>> use pg_ident.conf, and the only thing you can specify on a per-row basis
>> is "use map: yes or no". This decreases the flexibility, but would not
>> require the postmaster to do the parsing.
>
> I don't think it makes sense to have multiple different auth types using
> the same mappings... For Kerberos, as an example, we should support
> user(at)REALM as an option for the mapping, but that might not make sense
> for LDAP, which might have cn=User,ou=people,dc=example,dc=com, and
> neither of those really make sense for ident. Mashing all of those
> together would make each auth type supporting the mapping have to search
> through the list trying to make sense of some mappings and throwing away
> others, just ugly all around..

Yeah. I think the question there is just - how likely is it that the
same installation actually uses >1 authentication method. Personally, I
think it's not very uncommon at all, but fact remains that as long as
you only use one of them at a time, using a shared file doesn't matter.

>> What do people think about these? I know Stephen for example really want
>> that feature so - would that restriction make it a lot less useful for you?
>
> If we really wanted to keep it to a single *file*, then I think there
> should be a way to key rows in the pg_hba.conf to sets-of-rows in the
> mapping file. eg: have an option of 'mapkey=xyz' in pg_hba, and then
> 'xyz' as the first column of the mapping file, with it being repeated
> across rows to form that mapping table.

Yuck. Honestly, that seems even uglier :-)

> It wouldn't be very easy/clean to do that w/o breaking the existing
> structure of pg_ident though, which makes me feel like using seperate
> files is probably the way to go.

Yeah, thats my feeling as well. Now, can someone figure out a way to do
that without parsing the file in the postmaster? (And if we do parse it,
there's no point in not storing the parsed version, IMHO). And if not,
the question it comes down to is which is most important - keeping the
parsing away, or being able to do this ;-)

//Magnus