WARNING: 15.1 (pkgbase) upgrade resets PAM configurations.

[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:

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.)

 

[mer]

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.

 

[Eric A. Borisch]

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.

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.

 

[Eric A. Borisch]

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.)

 

[mer]

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.)

That is one thing I depend on with ZFS. I can boot into a BE, mount another one and copy files/compare things.

 

[mer]

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'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".

 

[Eric A. Borisch]

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.

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.

 

[mer]

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.

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"