>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.
>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.
Best regards,
Peifeng
