On Mon, Jul 12, 2021 at 5:43 AM Peifeng Qiu <peife...@vmware.com> wrote: > > >As you note, this'd have to be restricted to superusers, which makes it > >seem like a pretty bad idea. We really don't want to be in a situation > >of pushing people to run day-to-day stuff as superuser. Yeah, having > >access to kerberos auth sounds good on the surface, but it seems like > >it would be a net loss in security because of that. > > I can imagine the use case would be a superuser creates the user > mapping and foreign table, then grants access of foreign table to > a normal user. This way the normal user can execute queries on the > foreign table but can't access sensitive information in user mapping. > > The main purpose of this patch is to provide a simple way to do > kerberos authentication with the least modification possible.
But in this case, what dose Kerberos give over just using a password based solution? It adds complexity, but what's teh actual gain? > >ISTM the right way to do this would be using Kerberos delegation. That > >is, the system would be set up so that the postgres service principal > >is trusted for kerberos delegation and it would then pass through the > >actual Kerberos authentication from the client. > > I agree this sounds like the ideal solution. If I understand it correctly, > this approach requires both postgres servers to use same kerberos > settings(kdc, realm, etc), and the FDW server can just "forward" > necessary information to authenticate on behalf of the same user. > I will spend some time to investigate it and reach out later. I don't actually know if they have to be in the same realm, I *think* kerberos delegations work across trusted realms, but I'm not sure about that. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
