WARNING: 15.1 (pkgbase) upgrade resets PAM configurations.

Eric A. Borisch

Eric A. Borisch

N.B. If you don't modify PAM configurations to manage authentication/access, this is a non-issue for you.

Using the documented pkgbase upgrade procedure:

pkg -oABI=FreeBSD:15:$(uname -p) -oOSVERSION=1501000 upgrade -r FreeBSD-base

any local changes in /etc/pam.d seem to get overwritten without warning. (No .pkg* files or other l indications of conflicts).

Luckily I did this first in a VM, and I was able to directly roll back to a snapshot of the backing store taken before the upgrade without losing access.

Here is the closest it gets to a warning about this:

Code: 
Checking integrity... done (7 conflicting)
  - FreeBSD-sound-15.1 [FreeBSD-base] conflicts with FreeBSD-rc-15.0 [installed] on /etc/rc.d/mixer
  - FreeBSD-zstd-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p5 [installed] on /usr/lib/libprivatezstd.so.5
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p5 [installed] on /etc/pam.d/README
  - FreeBSD-pam-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p1 [installed] on /usr/lib/pam_chroot.so
  - FreeBSD-zstd-15.1 [FreeBSD-base] conflicts with FreeBSD-utilities-15.0p1 [installed] on /usr/bin/unzstd
  - FreeBSD-clang-15.1 [FreeBSD-base] conflicts with FreeBSD-lldb-15.0 [installed] on /usr/lib/libprivatelldb.so.19
  - FreeBSD-pam-lib-15.1 [FreeBSD-base] conflicts with FreeBSD-runtime-15.0p5 [installed] on /usr/lib/libpam.so.6
Checking integrity... done (0 conflicting)

Note it states the conflict on the /etc/pam.d/README (which it finally decides is not an issue, as FreeBSD-runtime-15.0p5 will be removed before FreeBSD-pam-15.1 lands) and pam_chroot.so, but not a whisper about /etc/pam.d/sshd. In my case, this was modified/reset to default, causing a loss of access: (.git in /etc was initialized and committed with initial state immediately before running the upgrade procedure the second time around on the rolled-back VM)

/etc/pam.d # git diff --name-status .
M pam.d/cron
M pam.d/sshd


(Cron gets a new :session required pam_permit.so"; but my custom /etc/pam.d/sshd configuration using pam_krb5.so was reset to stock.)

I suspect this is due to PAM being broken out into a separate installation package (FreeBSD-pam), and things not quite being handled correctly in this transition. (Perhaps checking for modification of configuration files when "upgrading" a package rather than just overwriting them when installing a "new" package.)
 
Question:
Does this also happen with freebsd-update or just pkgbase? Reason for asking is how configuration changes are handled. Merged or overwritten.

It sounds like /etc/pam.d needs to have a "defaults" like rc.d and other stuff.
 
mer said:
Question:
Does this also happen with freebsd-update or just pkgbase? Reason for asking is how configuration changes are handled. Merged or overwritten.

It sounds like /etc/pam.d needs to have a "defaults" like rc.d and other stuff.
Click to expand...

I will have to try on a system with freebsd-update, but I don't have one sitting around in that state to try just yet.
 
I would also like to note that on ZFS systems, following the upgrade procedure would also let you recover with a BE. I love and frequently use BEs and ZFS, but this lightweight VM is on ufs. (But the snapshot of the drive served as a similar, if less elegant, recovery point.)
 
Eric A. Borisch said:
I would also like to note that on ZFS systems, following the upgrade procedure would also let you recover with a BE. I love and frequently use BEs and ZFS, but this lightweight VM is on ufs. (But the snapshot of the drive served as a similar, if less elegant, recovery point.)
Click to expand...
That is one thing I depend on with ZFS. I can boot into a BE, mount another one and copy files/compare things.
 
Eric A. Borisch said:
I will have to try on a system with freebsd-update, but I don't have one sitting around in that state to try just yet.
Click to expand...
I'm guessing that if /etc/pam.d is in the paths that freebsd-update knows about for config modifications to merge it would do the right thing.
pkgbase I think would depend on the default behavior of how pkg merges configuration changes. I know some Linux tools (apt) will flag config file changes with "keep current, use package, merge".
 
mer said:
I'm guessing that if /etc/pam.d is in the paths that freebsd-update knows about for config modifications to merge it would do the right thing.
Click to expand...
I expect that's true; i think. But pkgbase is the future, and a supported path, so things like this need to get cleaned up.

While you can set PAMServiceName in sshd_config (and then create sshd_local or whatever you want to call it in /etc/pam.d), the typical use (at least in my experience) is to directly modify /etc/pam.d/sshd; treating it as a config file, and not as a "defaults/template" file that shouldn't be user-modified.
 
Eric A. Borisch said:
I expect that's true; i think. But pkgbase is the future, and a supported path, so things like this need to get cleaned up.

While you can set PAMServiceName in sshd_config (and then create sshd_local or whatever you want to call it in /etc/pam.d), the typical use (at least in my experience) is to directly modify /etc/pam.d/sshd; treating it as a config file, and not as a "defaults/template" file that shouldn't be user-modified.
Click to expand...
Agreed, I was thinking out loud, trying to figure out where/why it may have broken.

I guess this is where someone would normally say "I think this needs to be reported on bugzilla" :)
 
Eric A. Borisch said:
I expect that's true; i think. But pkgbase is the future, and a supported path, so things like this need to get cleaned up.

While you can set PAMServiceName in sshd_config (and then create sshd_local or whatever you want to call it in /etc/pam.d), the typical use (at least in my experience) is to directly modify /etc/pam.d/sshd; treating it as a config file, and not as a "defaults/template" file that shouldn't be user-modified.
Click to expand...
Confirmed: upgrading a similarly-equipped (custom /etc/pam.d/sshd) with freebsd-update retains the customization, with a git-diff showing only the expected modification to cron:

/etc/pam.d # git diff .
diff --git a/pam.d/cron b/pam.d/cron
index 7336313..4906635 100644
--- a/pam.d/cron
+++ b/pam.d/cron
@@ -6,3 +6,6 @@
# account
account required pam_nologin.so
account required pam_unix.so
+
+# session
+session required pam_permit.so
 
Eric A. Borisch said:
Confirmed: upgrading a similarly-equipped (custom /etc/pam.d/sshd) with freebsd-update retains the customization, with a git-diff showing only the expected modification to cron:

/etc/pam.d # git diff .
diff --git a/pam.d/cron b/pam.d/cron
index 7336313..4906635 100644
--- a/pam.d/cron
+++ b/pam.d/cron
@@ -6,3 +6,6 @@
# account
account required pam_nologin.so
account required pam_unix.so
+
+# session
+session required pam_permit.so
Click to expand...
Very cool. Thanks for doing the work to verify and submit bug.
I'm guessing not many people modify PAM stuff so upgrade is a noop, but for anyone that does, it's critical.
 
You must log in or register to reply here.
Back
Top