This is similar to Bug 238999. According to hier(7) /var/ and /var/run are suited for that and many many other ports put their variable data into it. Logically Makefile should set: > CONFIGURE_ARGS?= --enable-shared --without-system-verto \ > --disable-rpath --localstatedir="/var" \ > --runstatedir="/var/run" Out of many ports basically none use /usr/local/var.
Agreed.
(In reply to Cy Schubert from comment #1) Should I provide a review for this?
(In reply to Michael Osipov from comment #2) No. I am working to parameterize this. The other question is, what if people have put their KDC DB in /usr/local/var/run? I need to think that through.
(In reply to Cy Schubert from comment #3) Yes, that this the correct next question. Maybe test before configure if those are present and issue a warning? If not present, set new value. Give a grace of 3 to 6 months, add to UPDATING and switch at some point?
(In reply to Michael Osipov from comment #4) What about binary package users? Not everyone does make install. Most people use pkg install and pkg upgrade. Even I use pkg, after building using my own poudriere. Most people use binary packages. Some build using their own poudriere (like I do), while others build using make and make install (like you do). We cannot cause binary package users regressions. I have it building in a jail. I will work out a solution.
(In reply to Cy Schubert from comment #5) Right, what about pkg-install messages? They will apply to all, I guess. Let me know if there is anything you want me to test. Note: I use MIT Kerberos as client only. KDC is Active Directory here.
Testing will take a few days now. My poudriere queue is quite large.
(In reply to Cy Schubert from comment #7) Appreciated. Will happily wait until next month.
(In reply to Michael Osipov from comment #8) I can upload the two patches (in one file) if you want. It's been build tested in jail but not tested under poudriere or runtime tested yet. That should expedite things.
Created attachment 246641 [details] Partially tested patch This patch has been build tested. It is queued in my poudriere and will be install tested once complete. I doubt it will cause any KDC DB issues.
The patch causes krb5kdc not to find its database. The kdc.conf pathname is hardcoded in the binary. The best we can do is adjust runstatedir to point to /var/run and leave localstatedir default to $PREFIX/var. To be consistent the defaults will remain the same but you can still adjust them through KRB5_LOCALSTATEDIR and KRB5_RUNSTATEDIR in make.conf or on the make command line. Sorry but that's the best I can do without causing people to lose access to their KDC DB files. I'll post a new patch when tested. You will need to set $KRB5_LOCALSTATEDIR and $KRB5_RUNSTATEDIR in your make.conf. Make sure you note your KDC DB files and kdc.conf file, moving them to the new location before restarting your kdc. This is the best that can be done without causing other users a lot of grief.
Created attachment 246646 [details] Don't change default but give user the option This patch maintains the current default avoiding many angry FreeBSD MIT KRB5 users. But it gives you the option to put your KDC anywhere you want. I can't do anything else without a 100% certainty of reverting the change after a day or two.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=743dbb8f6fce110d31bff7ccf2652396cb53868a commit 743dbb8f6fce110d31bff7ccf2652396cb53868a Author: Cy Schubert <cy@FreeBSD.org> AuthorDate: 2023-11-28 03:58:58 +0000 Commit: Cy Schubert <cy@FreeBSD.org> CommitDate: 2023-11-28 23:49:24 +0000 security/krb5*: Allow the user to specify state directory locations localstatedir and runstatedir are set to ${PREFIX}/var and ${PREFIX}/var/run respectively. Users who wish to put their KDC DB elsewhere can set the following in make.conf: KRB5_LOCALSTATEDIR=/va KRB5_RUNSTATEDIR=/var/run. Unfortunately defaulting to /var instead of the current default would result in MIT KDC not finding its KDC DB files. This would be disruptive to all MIT KDC users. But new users of MIT KRB5 KDC can set the pathname above as desired. PR: 267560 security/krb5-119/Makefile | 13 +++++++++++-- security/krb5-119/pkg-plist | 4 ++-- security/krb5-120/Makefile | 13 +++++++++++-- security/krb5-120/pkg-plist | 4 ++-- security/krb5-121/Makefile | 13 +++++++++++-- security/krb5-121/pkg-plist | 4 ++-- security/krb5-devel/Makefile | 13 +++++++++++-- security/krb5-devel/pkg-plist | 4 ++-- 8 files changed, 52 insertions(+), 16 deletions(-)
(In reply to Cy Schubert from comment #12) Would you consider this a permanent default or for the current branches only? I would expect that 1.22 would use /var directly and users have to move once. I bet that only a fraction will actively set those make variables to stick to hier(7).
(In reply to Michael Osipov from comment #14) No. Because people don't recreate their KDC DB when updating FreeBSD base. This is a POLA issue. This would be too disruptive. We do this and it will be reverted within a few days of commit due to the number of PRs documenting KDC breakage. We could do a FLAVOR called @var. This way one could pkg install krb5@var instead of krb5@default. Would that be acceptable?
(In reply to Cy Schubert from comment #15) Maybe, but I wonder what the benefit would be and which people would explicitly use it. It don't think it is worth the effort since the actual (wrong) default won't change for POLA. This I understand. It could at most make sense when pkg-install would detect that ${LOCALBASE} is used and issue a warning. I will the decision ultimately upto you since you have a much better understanding. I think my request is satisfied with the contraints the system imposes.
(In reply to Michael Osipov from comment #16) No. It is not worth disrupting all those users who just after reboot discover their krb5kdc won't start (I discovered this after applying the patch), having to log into the console to look for their kdc.conf and move it and the DB to the new location. For me it was a PITA. For most everyone else, they will be stuck. The only way around this is to write a conversion script that would shut down krb5kdc, move the files to their new location, and start the krb5kdc up again as part of a post install script, not called by Makefile but inserted into the package by package-create. This would be buggy, could cause the loss of the KDC DB files and should it fail, how would you help them remotely from where you are many time zones away from end users who are panicked over the loss of their authentication data. And many of them won't say anything on the mailing lists or in bugzilla. Much of that chatter would be on the forums. It would be a mess. Been there, done that before. It's a horrible experience for the users and a horrible experience for the committer.
(In reply to Cy Schubert from comment #17) I agree with you.
(In reply to Michael Osipov from comment #18) Doesn't mean we can't plan for this in some way though. Remember, I am working on importing MIT KRB5 into base. Base will use /var and /var/run. But the Heimdal to MIT conversion will take time because the DB files are different format and the Heimdal kadmin protocol is not compatible with MIT. So a conversion will be needed once the grace period has expired. We could ride on the back of that effort at some point. This is long term. The reverse engineering of the MIT KRB5 GNU build Makefiles to create bespoke FreeBSD Makefiles is a slow and painful process. (There is not a one-to-one relationship between the build and resulting output in directories. This is the same headache when dealing with Heimdal build. Heimdal and MIT do the same horrible things in their builds.)
(In reply to Cy Schubert from comment #19) This I know, I personally dare to say that MIT Kerberos in base should solely be limited to the client libraries. Only a fraction of the users need a KDC and this can be provided by ports. For that reason BIND has been removed, unbound (if necessary at all) is enough and the rest for ports. Public surface of base should be as small as possible.
(In reply to Michael Osipov from comment #20) The reason BIND was removed is at the time there were three to four CVE announcements a year. We switched to unbound because it was more secure. I agree about no server components in base. This is why we are also replacing Sendmail with dma. This is why at some point, with MIT in base, all MIT libraries will be private. Ports and packages, and user built apps will not see any kerberos libraries. They will have to install krb5 or heimdal. The reason for this is if MIT is in base and they install heimdal the libraries will conflict with each other, just like MIT used to conflict with heimdal in base until I put a lot of work into MIT to have it work with a set of libraries with the same names in base. In a sense MIT in base will be the same as total removal of kerberos from base. Kerberos in base is supposed to only support ssh and PAM (ftp and telnet), and gss in kernel. We don't need kerberos in base for anything else.