8

I have a VPS that runs Ubuntu 14.04.4 LTS; it was installed as a whole with Plesk by OVH. I juste did a apt-get upgrade, and at some point I had a message regarding PAM. The system is in French, but basically it says:

At least one file of /etc/pam.d/common-{auth,account,password,session} was modified locally. Please indicate if local changes should be discarded and stick with the standard configuration. Otherwise you will have to configure the authentication system by yourself.

I decided to keep the local changes, and APT also reported:

pam-auth-update: Local modifications to /etc/pam.d/common-*, not updating.
pam-auth-update: Run pam-auth-update --force to override.

I want to know what are the differences between the local changes and the files the update wants to setup. How can I do that?

piwi
  • 336
  • 1
  • 3
  • 12
  • 3
    Looking at the two attempts to answer the question and a bit of documentation, I have a guess about what the problem is. I will leave this as a comment rather than as an answer, since I am not yet sure it is correct. I think whoever created the image has edited a file in `/etc/pam.d` without noticing the warning at the top of the file. Instead a file should have been added to `/usr/share/pam-configs` followed by running `pam-auth-update` to generate files in `/etc/pam.d`. – kasperd Apr 19 '16 at 15:55

4 Answers4

5

Because I did not want to alter the live configuration of PAM on the system, I ended up using a chroot jail to setup a default PAM configuration so I can view the differences:

# lsb_release --codename
Codename:       trusty
# debootstrap trusty /tmp/foo
I: Retrieving Release 
I: Retrieving Release.gpg 
  ...

View the differences:

for f in common-{account,auth,password,session,session-noninteractive}; do
  echo ==== $f ====
  diff --unified /etc/pam.d/$f /tmp/foo/etc/pam.d/$f
done
piwi
  • 336
  • 1
  • 3
  • 12
3

dpkg should prompt and allow you to see a diff (with D) in case there are changes made to your configuration files:

Configuration file `/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N]

Update: from the comment below the problem is with packages that don't drop complete configuration files (which is where the above behaviour is triggered), but with files that use a scripted approach to generate configuration files. The Debian policy manual describes that as:

E.2 Fully-featured maintainer script configuration handling

For files which contain site-specific information such as the hostname and networking details and so forth, it is better to create the file in the package's postinst script.

This will typically involve examining the state of the rest of the system to determine values and other information, and may involve prompting the user for some information which can't be obtained some other way.

When using this method there are a couple of important issues which should be considered:

If you discover a bug in the program which generates the configuration file, or if the format of the file changes from one version to the next, you will have to arrange for the postinst script to do something sensible - usually this will mean editing the installed configuration file to remove the problem or change the syntax. You will have to do this very carefully, since the user may have changed the file, perhaps to fix the very problem that your script is trying to deal with - you will have to detect these situations and deal with them correctly.

If you do go down this route it's probably a good idea to make the program that generates the configuration file(s) a separate program in /usr/sbin, by convention called packageconfig and then run that if appropriate from the post-installation script. The packageconfig program should not unquestioningly overwrite an existing configuration - if its mode of operation is geared towards setting up a package for the first time (rather than any arbitrary reconfiguration later) you should have it check whether the configuration already exists, and require a --force flag to overwrite it.

That means you need to rely on the packageconfig program, for PAM /usr/sbin/pam-auth-update, to provide a dry-run or preview option.

And as far as I can tell /usr/sbin/pam-auth-update does not offer such a feature.

Community
  • 1
HBruijn
  • 77,029
  • 24
  • 135
  • 201
  • 3
    I think you are mistaken. The prompt you mention works for files installed directly from the package by `apt-get` or `dpkg`. But the files in `/etc/pam.d` are not installed that way. Instead they are installed by a post install script. Notice the difference in output between `dpkg-query -S /etc/bash.bashrc` and `dpkg-query -S /etc/pam.d/common-auth`. – kasperd Apr 19 '16 at 15:36
2

You could make a copy of the whole directory and then run a diff on each file to check for differences

cp -r /etc/pam.d/ /home/<user>/
pam-auth-update --force
diff /etc/pam.d/ /home/<user>/pam.d

Once carefully going through each diff you can then decide if you want to keep the changes or revert back to the old ones. Reverting is as simple as copying the files back to where they were

Frederik
  • 3,359
  • 3
  • 32
  • 46
  • 1
    I thought about this solution but I don't want to change the PAM configuration before reviewing changes; I'm looking for a mean to inspect the changes without changing the behavior of the system. – piwi Apr 19 '16 at 16:00
  • I can follow you on this one but I can't seem to think of any other way to do it. A less interruptive way would be to make a script that first makes a backup, overwrites the old ones and copying them to another place before restoring the original ones back to where they should be. This process should limit the amount of time the PAM configuration is changed. – Frederik Apr 20 '16 at 08:02
  • The thing is, I assume `pam-auth-update` has to get its new configuration from somewhere; where is it? – piwi Apr 20 '16 at 08:26
  • 1
    @piwi If you type `man pam-auth-update` you will learn that it gets the new configuration from `/usr/share/pam-configs/`. – kasperd Apr 20 '16 at 13:20
  • @kasperd I saw that in the manual, but the files in `/usr/share/pam-configs` have drastically different syntax from `/etc/pam.d/common-*` ones. I have no knowledge of PAM internals so I don't know how to "translate" these files into the `etc` ones. – piwi Apr 20 '16 at 13:24
  • 1
    @piwi That part I don't know either. So an answer explaining that would have a better chance of getting the bounty. It would also be very convenient, if there was some way to tell `pam-auth-update` to write the output to a different directory. That could even be used as an unprivileged user. – kasperd Apr 20 '16 at 13:27
  • @kasperd See my answer for the workaround I settled with. – piwi Apr 21 '16 at 08:47
  • This is the answer I wanted to read. I was unsure whether I could accept the changes and still have access to the system in order to decide whether to keep or revert. Turns out nothing happened after I accepted the changes. I managed to make a backup before and after and diff them successfully. Thanks! – GuiRitter May 22 '22 at 19:42
0

I just had this problem. In the end, I let pam-auth-update --force change the files -- then noticed that it had also saved a copy of the old files (e.g. as /etc/pam.d/common-foo.pam.old). The below one-liner then showed me the diffs:

for old in *.pam-old; do new="${old:0:-8}"; echo "=== $new ==="; diff $old $new; done

It:

  1. Loops through backup copies;
  2. Strips the last 8 chars to get the name of the new file;
  3. Echos the filename (so we can see which contains each change); and
  4. Diffs the old and new files
Steve Almond
  • 123
  • 7