The PostgreSQL ports support building with the usual Kerberos variants: base, ports Heimdal, ports MIT. The way they do this, however, breaks badly when building within poudriere. Poudriere builders have no packages installed initially, and prepare for each port build by installing the packages declared as dependencies by the port. Hence, any dependency undeclared by the port, e.g. as LIB_DEPENDS, will not be satisfied during build. The PostgreSQL ports are affected by this because they: - declare a dependency on security/krb5 only if it is already installed - never declare a dependency on security/heimdal at all
I'll check this out.
I seem to remeber that Kerberos is either not supported, or at least gravely deprecated, in favour of GSSAPI. I has been on my list to chekt this out for some time.
The "krb5" authentication method was removed in 9.4, yes, and this results in a warning from configure in 9.[456] about "--with-krb5" being an unknown option. I thought about reporting that, too, but decided it wasn't important enough to require building different CONFIGURE_ARGS in different port versions. For *this* bug that does not matter because the GSSAPI implementations come from the Kerberos suites. GSSAPI is an abstraction layer (similar to SASL and SSPI) after all, and one of the authentication mechanisms it supports happens to be Kerberos.
(In reply to Christian Ullrich from comment #3) Quite so. I just thought that since GSSAPI requires less dependencies on the kerberos installation, the base heimdal could suffice, and we would not have to bother about which Kerberos port that is installed.
(In reply to Palle Girgensohn from comment #4) The problem is that having multiple Kerberoses in the same system is a steady source of trouble. I have had a lot of not-fun in the past with things like Samba and PostgreSQL picking up the wrong one even at run time, so these days I build my worlds WITHOUT_KERBEROS, i.e. omit the base Heimdal entirely. Anyway, the ports collection has good support for selecting one's favorite Kerberos through USES=gssapi. I'm not sure whether library selection through /etc/gss/mech is supposed to work cross-package, i.e. let you use ports MIT's implementation of something with your application linked against base Heimdal, but I rather doubt it. At API level, MIT and Heimdal are too different. For example (from MIT's gssapi_krb5.h): /* Alias for Heimdal compat. */ #define gsskrb5_register_acceptor_identity krb5_gss_register_acceptor_identity OM_uint32 KRB5_CALLCONV krb5_gss_register_acceptor_identity(const char *); This may let code that expects the Heimdal function name build against MIT, but it is no help at run time, where the dynamic linker clearly has no hope of matching up the symbols.
The recent update to, among other things, 9.6.4 and 9.2.22, now breaks the poudriere build (at least in my configuration; base WITHOUT_KERBEROS and with security/krb5 installed) entirely and with no feasible workaround. Included in the update is a change to the clan elder of the family of PostgreSQL ports, databases/postgresql92-server, which removes the MIT_KRB5 and HEIMDAL_KRB5 port options from all ports from version 9.4 onwards. Instead, it falls back to simply adding -lgssapi to LDFLAGS. No such library exists in MIT, and therefore the configure script fails right at the start: configure:3884: checking whether the C compiler works configure:3906: cc -O -pipe -march=haswell -O3 -funroll-loops -fstack-protector -fno-strict-aliasing -I/usr/local/include -L/usr/local/lib -lpthread -lgssapi -L/usr/local/lib -Wl,-rpath,/usr/local/lib -fstack-protector conftest.c >&5 /usr/bin/ld: cannot find -lgssapi cc: error: linker command failed with exit code 1 (use -v to see invocation) [...] configure:3953: error: in `/wrkdirs/usr/ports/databases/postgresql96-client/work/postgresql-9.6.4': configure:3956: error: C compiler cannot create executables This worked before the update because the spurious -lgssapi option was not added in the presence of both the GSSAPI and MIT_KRB5 port options. I will also point out, again, that relying on base Heimdal's libgssapi does not work because a) it may not be there at all, and b) even if it is, the "active" Kerberos on any given system may be from ports. I'm not sure how to fix this properly, but my best guess is: - Reinstate the MIT_KRB5 and HEIMDAL_KRB5 options for all versions. - To avoid the configure warning I mentioned earlier (though I could care less) only leave out --with-krb5 from CONFIGURE_ARGS in 9.4+. - Use the *_KRB5 and GSSAPI options to build a correct USES option, and leave the details to that machinery.
Also, I just read your comment in #215950 as well as comment no. 4 here, and I think we are simply talking about different things here. You seem to think that – any, but particularly the one in base – GSSAPI is an interface layer that can use any Kerberos implementation on the "backend". This is not correct. The well-standardized GSSAPI is the interface to the consumer only, that is, the C API used by services to support GSSAPI authentication, and the ASN.1 data structures used by (network) clients. There is not a whole second interoperability layer between GSSAPI and the underlying Kerberos. Each Kerberos has its own GSSAPI, but each of the various GSSAPIs looks the same to the consumer as any other. Applied to PostgreSQL, this means that the GSSAPI port option controls whether the "gss" authentication method is supported, and the *_KRB5 options control where the GSSAPI comes from. Before 9.4, they also control which Kerberos is used for the "krb5" authentication method. Considering only the 9.4 and later ports, what the port options are supposed to mean is this: - GSSAPI: Build with base Heimdal, enable "gss" auth - GSSAPI && MIT_KRB5: Build with security/krb5, enable "gss" auth - GSSAPI && HEIMDAL_KRB5: Build with security/heimdal, enable "gss" auth - MIT_KRB5: Build without GSSAPI support - HEIMDAL_KRB5: Build without GSSAPI support - (none): Build without GSSAPI support That is, if GSSAPI is on, then the *_KRB5 options control which of the Kerberos distributions provides its GSSAPI implementation, and if GSSAPI is off, there is no Kerberos support at all.
Hello, I have apparently misunderstood the GSSAPI part on the server side, thanks for clarifying that. I need to setup a poudriere jail WITHOUT_KERBEROS. Do you have a suggestion how to quickly do that? Just build from source and install to a DESTDIR, and the poudriere jail -m null -M /destdir ? Palle
(In reply to Palle Girgensohn from comment #8) I would do this, to let poudriere itself build the jail: # echo WITHOUT_KERBEROS=yes > /usr/local/etc/poudriere.d/nokerberos-src.conf # poudriere jail -c -j nokerberos -m svn -v stable/11 Adjust -v to taste, of course.
Created attachment 185529 [details] Sample patch This is what I have been able to come up with. It looks quite ugly because many options are essentially repeated. Unfortunately the port options support is not able to model "radio"-type option groups where each option has a specific effect, but selecting _any_ one has another. It builds successfully with all combinations of BASE/MIT/HEIMDAL and GSSAPI/!GSSAPI (in 9.[23]), for client and server of all versions. Since it builds, I must assume (but have not tested) that it will also run. The duplicated *_KRB5/GSSAPI_* options are to keep the options' names consistent for each version. They could probably be combined into the *_KRB5 names. I removed the block that excludes building with MIT if base Heimdal exists because it looks like a NOP to me; the variable it's conditional on is never defined anywhere.
If you wish you can new projects/krb5. Heimdal in base is private and won't interfere with Heimdal or MIT in base. It's probably best to try this on a sandbox VM or non-production machine as it's probably best not to deviate from head or stable in those instances.
(In reply to Christian Ullrich from comment #10) This patch makes some sense regardless of how we do Kerberos in base.
Created attachment 190807 [details] Patch updated against databases/postgresql10-server
It does not only break with poudriere, it breaks with other build&deploy schemes also. I agree with Palle Girgenson (#4) that the Heimdal in base does suffice for all that postgres would need. But now we have pgadmin4, and it requires Gssapi credstore extensions in order to copy the creds (as received from the browser via spnego) over to postgres - and that extension is currently only available in MIT kerberos. And this gets runtime-linked together with the libpq.so into the same image, and also the webserver used (apache, uwsgi, whatever) gets linked into the same image, and a webserver might do other things with spnego, which may also need certain extensions. A proper instance to *run* such a zoo can certainly be created, but then we do not want to extra adjust/hack/fix our deploy system (poudriere or elsewise) in order to build and link the packages as required. The port options to choose the kerberos implementation are only present for postgresql <= 9.3. There is no means to choose for newer versions; these will always link with the Heimdal in base (and, according to bug #225801, the build just fails if that has been removed). What I am currently doing: I switch *OFF* the GSSAPI option (because it always produces a LDFLAGS+=-lgssapi linker feature, which will make configure to always use the Heimdal. (I didn't understand the comment in the Makefile about DT_NEEDED - maybe something will bite me there and I don't know it yet). And then, individually for the specific instance that the images are built for, that should get MIT instead of base gssapi, I prepend the make from /etc/make.conf with this snippet: .if ${.CURDIR:C/.*\/databases\/postgresql[0-9]+-(client|server)//} == "" GSSAPI_CONFIGURE_OFF=--with-gssapi GSSAPI_VARS_OFF=USES+=gssapi:mit .endif This appears to produce something working, i.e it creates the necessary prereq and it seems to link how it should, to use MIT kerberos. But I would much appreciate to get the radio buttons, like many other ports have them - that would make things simpler.
Created attachment 254243 [details] Use standard gssapi.mk variables for databases/postgresql16-server As a result of this bug, it is actually now impossible to build PostgreSQL 16 from FreeBSD ports with GSSAPI support. Version 16 depends on some newer krb5 functions that do not exist in the base system's ancient Heimdal distribution. The attached patch modifies the postgresql Makefile to use gssapi.mk, along with the standard GSSAPI_ option names used by most other ports. Tested with MIT kerberos and postgresql16. Bug 225801, Bug 276030, and Bug 236037 are all related to this issue.
(In reply to Cullum Smith from comment #15) The standalone GSSAPI option (in OPTIONS_DEFINE) should be removed. The GSSAPI_*_DESCs have defaults in bsd.options.desc.mk and can be deleted as well.
(In reply to Cullum Smith from comment #15) Thank You, Cullum. Let's hope we can motivate the maintainer to change this. But what You're talking about seems to be a bigger issue. You say postgres 16 no longer /build/ with Heimdal in Base. Does this also mean that it does no longer /run/ with it? Because, hacking the deploy machine is one thing, changing the Kerberos in production is yet another. I had currently no intention to follow the switch to 16. But if this becomes an issue, one must see to it, before some application might suddenly need 16. I checked the release notes, and only found sparse mention of some credential delegation, but no details. And I do not yet see the possible usecase for such. Do You have some source of input for me?
(In reply to Peter Much from comment #17) Correct. This is because PostgreSQL 16 calls some newer KRB5 related functions which are not present in the Heimdal version in base, which is quite old. Bug 276030 describes this specific issue. The Heimdal version in base would either need to be upgraded to a newer version, or patched to support the newer functions. Or, you can just build PostgreSQL 16 against the MIT or Heimdal kerberos in ports. However, due to this bug, that currently not possible for Poudriere without patching the Makefile.
has there been any progress on this? i'm happy to build with security/krb5 instead of base Kerberos (in fact i prefer that) but this doesn't seem to be possible right now, meaning it's impossible to compile Postgres with Kerberos support.
It doesn't look like there is any appetite for the maintainers to merge my patch. But I am still using it to run PostgreSQL 16 with security/krb5 (MIT Kerberos) in my environment for multiple months now without issues. I run a local poudriere server and just have a build script that applies my patch before running `poudriere-bulk`. Not ideal, but it does the job.
(In reply to Cullum Smith from comment #20) Hi! I'm just truggling a bit doing the right thing here. It seems that since we have Heimdal in base, using the patch will catch the base heimdal still fail even if I config the port to use the more updated package. checking for library containing gss_store_cred_into... no configure: error: could not find function 'gss_store_cred_into' required for GSSAPI ===> Script "configure" failed unexpectedly. ===> The following configuration options are available for postgresql16-server-16.7: DEBUG=off: Build with debugging support DOCS=on: Build and/or install documentation DTRACE=off: Build with DTrace probes GSSAPI=on: GSSAPI Security API support LDAP=off: Build with LDAP authentication support LLVM=on: Build with support for JIT-compiling expressions LZ4=on: Build with LZ4 compression support NLS=off: Use internationalized messages OPTIMIZED_CFLAGS=on: Builds with compiler optimizations (-O3) PAM=off: Build with PAM Support SSL=on: Build with OpenSSL support TZDATA=on: Use internal timezone database XML=on: Build with XML data type ZSTD=on: Build with ZSTD compression support ====> GSSAPI Security API support: you have to select exactly one of them GSSAPI_NONE=off: Build without GSSAPI support GSSAPI_BASE=off: Use GSSAPI from base GSSAPI_HEIMDAL=on: Use Heimdal GSSAPI from security/heimdal GSSAPI_MIT=off: Use MIT GSSAPI from security/krb5 So, is your suggestion not to support heiumdal at all? Or do I need to build a version of the base system without heimdal to even get that option to build? Or can I pin it to the package version? Please advice. Palle
(In reply to Palle Girgensohn from comment #21) Thanks for catching. My patch should be updated to only support MIT kerberos. The version of heimdal in base does not have the required function (gss_store_cred_into). Turns out the version of heimdal in ports (7.8.0) doesn't have it either! It *is* in heimdal-devel, but I dont think any other ports support linking against that. I will update my patch to support a single option (GSSAPI) which links against security/krb5.
Created attachment 257471 [details] Change GSSAPI option use security/krb5 Postgresql fails to build against the base heimdal or the heimdal in ports due to a missing krb5 function (gss_store_cred_into). This patch changes the GSSAPI option to use security/krb5 (MIT kerberos) and obsolesces the old MIT_KRB5 and HEIMDAL_KRB5 options.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=1d902ba9366536c6034cc8c26a89b289046201ec commit 1d902ba9366536c6034cc8c26a89b289046201ec Author: Palle Girgensohn <girgen@FreeBSD.org> AuthorDate: 2025-02-13 14:48:59 +0000 Commit: Palle Girgensohn <girgen@FreeBSD.org> CommitDate: 2025-02-13 15:13:24 +0000 databases/postgresql??-*: Update to latest versions The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 17.3, 16.7, 15.11, 14.16, and 13.19. This release fixes 1 security vulnerability and over 70 bugs reported over the last several months. For the full list of changes, please review the release notes. This commit also removes the broken support for Heimdal and fixes the build when using MIT Kerberos. [1] PR: 220325 suggested by Cullum Smith and many others. [1] Release notes: https://www.postgresql.org/docs/release/ Security: fadf3b41-ea19-11ef-a540-6cc21735f730 databases/postgresql13-server/Makefile | 2 +- databases/postgresql13-server/distinfo | 6 ++-- databases/postgresql14-server/Makefile | 2 +- databases/postgresql14-server/distinfo | 6 ++-- databases/postgresql15-server/Makefile | 2 +- databases/postgresql15-server/distinfo | 6 ++-- databases/postgresql16-server/Makefile | 37 ++------------------- databases/postgresql16-server/distinfo | 6 ++-- databases/postgresql16-server/pkg-plist-contrib | 1 + databases/postgresql17-server/Makefile | 43 +++---------------------- databases/postgresql17-server/distinfo | 6 ++-- databases/postgresql17-server/pkg-plist-contrib | 1 + 12 files changed, 28 insertions(+), 90 deletions(-)
Committed. Thanks for the immense patience!
*** Bug 225801 has been marked as a duplicate of this bug. ***
A commit in branch 2025Q1 references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=f5397f11e41d559aa73cc7668af5492ae34fdc33 commit f5397f11e41d559aa73cc7668af5492ae34fdc33 Author: Palle Girgensohn <girgen@FreeBSD.org> AuthorDate: 2025-02-13 14:48:59 +0000 Commit: Palle Girgensohn <girgen@FreeBSD.org> CommitDate: 2025-02-21 21:16:22 +0000 databases/postgresql??-*: Update to latest versions The PostgreSQL Global Development Group has released an update to all supported versions of PostgreSQL, including 17.3, 16.7, 15.11, 14.16, and 13.19. This release fixes 1 security vulnerability and over 70 bugs reported over the last several months. For the full list of changes, please review the release notes. This commit also removes the broken support for Heimdal and fixes the build when using MIT Kerberos. [1] PR: 220325 suggested by Cullum Smith and many others. [1] Release notes: https://www.postgresql.org/docs/release/ Security: fadf3b41-ea19-11ef-a540-6cc21735f730 (cherry picked from commit 1d902ba9366536c6034cc8c26a89b289046201ec) databases/postgresql13-server/Makefile | 2 +- databases/postgresql13-server/distinfo | 6 ++-- databases/postgresql14-server/Makefile | 2 +- databases/postgresql14-server/distinfo | 6 ++-- databases/postgresql15-server/Makefile | 2 +- databases/postgresql15-server/distinfo | 6 ++-- databases/postgresql16-server/Makefile | 37 ++------------------- databases/postgresql16-server/distinfo | 6 ++-- databases/postgresql16-server/pkg-plist-contrib | 1 + databases/postgresql17-server/Makefile | 43 +++---------------------- databases/postgresql17-server/distinfo | 6 ++-- databases/postgresql17-server/pkg-plist-contrib | 1 + 12 files changed, 28 insertions(+), 90 deletions(-)