Re: pg16 && GSSAPI && Heimdal/Macos
От | Tom Lane |
---|---|
Тема | Re: pg16 && GSSAPI && Heimdal/Macos |
Дата | |
Msg-id | 24600.1741460579@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pg16 && GSSAPI && Heimdal/Macos ("Todd M. Kover" <kovert@omniscient.com>) |
Ответы |
Re: pg16 && GSSAPI && Heimdal/Macos
|
Список | pgsql-hackers |
"Todd M. Kover" <kovert@omniscient.com> writes: > To that end, I'd like to propose a --with-gssapi-client-only type option > that's mutually exclusive with --with-gssapi that will trigger gssapi > linkage in just libpq but not in the backend. --with-gssapi would just > turn on the same flag that --with-gssapi-client-only uses. I don't see how that's a good idea. Notably, a system built that way could not test its own GSS support. Looking at the code a bit closer, I see that we will never try to call gss_store_cred_into() unless the gss_accept_delegation GUC is on --- which it is not by default. So that certainly blows a large hole in the idea that this is something we have to have. I think that a more-probably-acceptable patch would be to set up the code so that we can build without gss_store_cred_into() and what the user sees is gss_accept_delegation can't be turned on. I remain doubtful that this is a good idea from a big-picture standpoint, though. What this amounts to is un-desupporting the Heimdal Kerberos libraries, which is a big deal from a testing standpoint if nothing else. Plus we'd be encouraging people to depend on security-critical software that is, if not effectively dead, at best in back-burner maintenance mode. Is there a good reason why you can't build your Mac PG code with MIT Kerberos from Homebrew or MacPorts? regards, tom lane
В списке pgsql-hackers по дате отправления: