"PAM account management error"

Hi,

The following error is from a classic snap (MicroK8s) while calling sed during a daemon startup on CentOS and Fedora 29. Has anyone seen this before? Any hints on how to address it?

Oct 31 17:45:23 noc.uftwf.local sudo[7221]: PAM unable to dlopen(/usr/lib64/security/pam_unix.so): /snap/core/current/lib/x86_64-linux-gnu/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /usr/lib64/security/pam_unix.so)
Oct 31 17:45:23 noc.uftwf.local sudo[7221]: PAM adding faulty module: /usr/lib64/security/pam_unix.so
Oct 31 17:45:23 noc.uftwf.local sudo[7221]: root : PAM account management error: Module is unknown ; TTY=unknown ; PWD=/var/snap/microk8s/993 ; USER=root ; COMMAND=/snap/microk8s/993/bin/sed -i $ a --runtime-cgroups=/systemd/system.slice /var/snap/microk8s/993/args/kubelet

The problem is reported in [1] and [2] and
the code that causes this is in [3]

[1] https://github.com/ubuntu/microk8s/issues/769
[2] https://github.com/ubuntu/microk8s/issues/671
[3] https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/actions/common/utils.sh#L79

1 Like

@kjackal thank you for linking to my issue on github)

This isn’t a fix, but rather a diagnosis of the problem.

First of all, the error looks like it comes from the sudo process rather than sed: PAM is a library intended for use by utilities dealing in user authentication.

As we’re dealing with a classic snap, the host system’s libraries are visible. In this case, it appears that libpam has picked up the authentication modules from the host system. One of those modules links to libcrypt.so.1, and due to the fact the snap is setting LD_LIBRARY_PATH it ends up trying to load the copy of the library distributed with the snap:

https://github.com/ubuntu/microk8s/blob/master/microk8s-resources/wrappers/run-with-config-args#L5-L6

That library appears to be older than the version on the host system, so the PAM module fails to load. This is one of the pitfalls of developing a classic confinement snap compared to strict confinement.

As for this particular case: it is not at all clear why sudo is being used here. The daemon is already running as root, and has write access to the configuration file in $SNAP_DATA. And if it didn’t, there is no way that sudo could prompt for a password while the daemon is starting.

Thank you @jamesh for the insight. The setting LD_LIBRARY_PATH proves to be problematic for sudo as the later is coming from the host. The solution (as suggested in the #snappy channel) I found is to unset the LD_LABRARY_PATH right before calling sudo and reseting it for the command called. This PR https://github.com/ubuntu/microk8s/pull/773 seems to be doing the trick. I need to test it a bit more before merging it, thanks.