Bug 1215596

The following 3 packages are going to be upgraded:
  apparmor-parser libapparmor1 pam_apparmor

The following NEW package is going to be installed:
  apparmor-parser-lang

The following NEW patch is going to be installed:
  SUSE-SLE-Module-Basesystem-15-SP5-2023-3717

3 packages to upgrade, 1 new.
Overall download size: 775.2 KiB. Already cached: 0 B. After the operation, additional 433.9 KiB will be used.
Continue? [y/n/v/...? shows all options] (y): y
Retrieving: apparmor-parser-3.0.4-150500.11.6.1.x86_64 (SLE-Module-Basesystem15-SP5-Updates) (1/4), 525.0 KiB    
Retrieving: apparmor-parser-3.0.4-150500.11.6.1.x86_64.rpm [.Retrieving: apparmor-parser-3.0.4-150500.11.6.1.x86_64.rpm [.done]
Retrieving: libapparmor1-3.0.4-150500.11.6.1.x86_64 (SLE-Module-Basesystem15-SP5-Updates) (2/4),  74.7 KiB    
Retrieving: libapparmor1-3.0.4-150500.11.6.1.x86_64.rpm [.done]
Retrieving: apparmor-parser-lang-3.0.4-150500.11.6.1.noarch (SLE-Module-Basesystem15-SP5-Updates) (3/4), 125.9 KiB    
Retrieving: apparmor-parser-lang-3.0.4-150500.11.6.1.noarch.rpm [.done]
Retrieving: pam_apparmor-3.0.4-150500.11.6.1.x86_64 (SLE-Module-Basesystem15-SP5-Updates) (4/4),  49.6 KiB    
Retrieving: pam_apparmor-3.0.4-150500.11.6.1.x86_64.rpm [.done]

Checking for file conflicts: [....done]
(1/4) Installing: apparmor-parser-3.0.4-150500.11.6.1.x86_64 [......done]
(2/4) Installing: libapparmor1-3.0.4-150500.11.6.1.x86_64 [....done]
(3/4) Installing: apparmor-parser-lang-3.0.4-150500.11.6.1.noarch [.....done]
(4/4) Installing: pam_apparmor-3.0.4-150500.11.6.1.x86_64 [..
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
warning: %post(pam_apparmor-3.0.4-150500.11.6.1.x86_64) scriptlet failed, exit status 1
.
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
warning: %postun(pam_apparmor-3.0.4-150500.11.3.1.x86_64) scriptlet failed, exit status 1
done]
There are running programs which still use files and libraries deleted or updated by recent upgrades. They should be restarted to benefit from the latest updates. Run 'zypper ps -s' to list these programs.

Thanks for the report. On the apparmor side there haven't been any recent changes in this area that I'm aware of. The postun script carries:
  %postun -n pam_apparmor
  pam-config -d --apparmor
  pam-config --update

Which should simply remove pam_apparmor.so usage from the existing pam configuration. Looks like I'll need to look closer at the pam configuration state at the time of the pam-config calls.
I'm not to familiar with out cloud specific images: are you able to provide a dump of etc on the test system, or would I be better off deploying a test image myself on QEMU/Azure?

(In reply to David Disseldorp from comment #2)
> I'm not to familiar with out cloud specific images: are you able to provide
> a dump of etc on the test system, or would I be better off deploying a test
> image myself on QEMU/Azure?

Thanks David, for the prompt response. I will get you the content of etc.

Created attachment 869690 [details]
etc

(In reply to David Disseldorp from comment #2)
> Thanks for the report. On the apparmor side there haven't been any recent
> changes in this area that I'm aware of. The postun script carries:
>   %postun -n pam_apparmor
>   pam-config -d --apparmor
>   pam-config --update
> 
> Which should simply remove pam_apparmor.so usage from the existing pam
> configuration. Looks like I'll need to look closer at the pam configuration
> state at the time of the pam-config calls.

On the broken system we have (ignore the owner):

-rw-r--r-- 1 david users 1075 Sep 20 18:32 common-account
-rw-r--r-- 1 david users  380 Oct  3  2022 common-account.pam-config-backup
-rw-r--r-- 1 david users 1037 Sep 20 18:31 common-account-pc
-rw-r--r-- 1 david users 1250 Sep 20 18:32 common-auth
-rw-r--r-- 1 david users  462 Oct  3  2022 common-auth.pam-config-backup
-rw-r--r-- 1 david users 1198 Sep 20 18:31 common-auth-pc
-rw-r--r-- 1 david users   95 May  5  2019 common-auth-smartcard
-rw-r--r-- 1 david users 1241 Sep 20 18:32 common-password
-rw-r--r-- 1 david users  510 Oct  3  2022 common-password.pam-config-backup
-rw-r--r-- 1 david users 1151 Sep 20 18:32 common-password-pc
-rw-r--r-- 1 david users 1243 Sep 20 18:31 common-session
-rw-r--r-- 1 david users  482 Oct  3  2022 common-session.pam-config-backup
-rw-r--r-- 1 david users 1243 Sep 20 18:31 common-session-pc

While on my relatively stock, working 15-SP5 system we have:

lrwxrwxrwx 1 root root   17 Aug  9 15:24 common-account -> common-account-pc
-rw-r--r-- 1 root root  380 Oct  3  2022 common-account.pam-config-backup
-rw-r--r-- 1 root root 1037 Sep 22 21:42 common-account-pc
lrwxrwxrwx 1 root root   14 Aug  9 15:24 common-auth -> common-auth-pc
-rw-r--r-- 1 root root  462 Oct  3  2022 common-auth.pam-config-backup
-rw-r--r-- 1 root root 1198 Sep 22 21:42 common-auth-pc
lrwxrwxrwx 1 root root   18 Aug  9 15:24 common-password -> common-password-pc
-rw-r--r-- 1 root root  510 Oct  3  2022 common-password.pam-config-backup
-rw-r--r-- 1 root root 1091 Sep 22 21:42 common-password-pc
lrwxrwxrwx 1 root root   17 Aug  9 15:24 common-session -> common-session-pc
-rw-r--r-- 1 root root  482 Oct  3  2022 common-session.pam-config-backup
-rw-r--r-- 1 root root 1243 Sep 22 21:42 common-session-pc

The X -> X-pc symlink presence is checked by pam-config.c:

1085   if (!gl_service)                                                                
1086     {                                                                             
1087       if (check_symlink (confdir, CONF_ACCOUNT_PC, CONF_ACCOUNT) != 0)            
1088         retval = 1;                                                               
1089       if (check_symlink (confdir, CONF_AUTH_PC, CONF_AUTH) != 0)                  
1090         retval = 1;                                                               
1091       if (check_symlink (confdir, CONF_PASSWORD_PC, CONF_PASSWORD) != 0)          
1092         retval = 1;                                                               
1093       if (check_symlink (confdir, CONF_SESSION_PC, CONF_SESSION) != 0)            
1094         retval = 1;                                                               
1095     }                                                                             
1096                                                                                   
1097   return retval; 

Where check_symlink calls:
 172       if (readlink (config, buf, sizeof (buf)) <= 0 ||
 173           strcmp (file_pc, basename(buf)) != 0)
 174         {
 175           fprintf (stderr,
 176                    _("File %s is no symlink to %s.\n"), config, file_pc);

So this pam-config error is caused by something avoiding / removing the link between common-X and common-X-pc . Interestingly the separate files have also diverged.
As a workaround it seems that the links can be restored by using the --force option, e.g. "pam-config --update --force". However, to properly resolve this issue we'll need to find out what's responsible for causing the unexpected link state.

(In reply to David Disseldorp from comment #5)
...
> So this pam-config error is caused by something avoiding / removing the link
> between common-X and common-X-pc . Interestingly the separate files have
> also diverged.

Looking at the common-X-pc vs common-X divergence, we see:

diff common-account-pc common-account:
30a31
> account    required    pam_tally2.so 
diff common-auth-pc common-auth:
33c33,34
< auth  required        pam_unix.so     try_first_pass 
---
> auth  required        pam_unix.so     try_first_pass  sha512
> auth required pam_faildelay.so delay=4000000
diff common-password-pc common-password:
30,31c30,32
< password      requisite       pam_cracklib.so minlen=6 dcredit=1 ucredit=1 lcredit=1 ocredit=1 minclass=3
< password      required        pam_unix.so     use_authtok nullok shadow try_first_pass 
---
> password      requisite       pam_cracklib.so minlen=15 dcredit=-1 ucredit=-1 lcredit=-1 ocredit=-1 minclass=3         difok=8  retry=3 
> password      required        pam_unix.so     use_authtok nullok shadow try_first_pass  sha512
> password requisite pam_pwhistory.so remember=5  use_authtok
diff common-session-pc common-session:

Which would indicate that a user or utility attempted to manually configure more cautious/restrictive PAM behaviour. @Martin: do you know who / what is responsible for the pam configuration changes above?

We provide (relatively old) documentation which instructs users to remove the -pc symlink when manually changing the PAM configuration: https://www.suse.com/support/kb/doc/?id=000018934 so it looks like this kind of divergence should be acceptable.

> As a workaround it seems that the links can be restored by using the --force
> option, e.g. "pam-config --update --force". However, to properly resolve
> this issue we'll need to find out what's responsible for causing the
> unexpected link state.

I think I'll need to get someone with more PAM knowledge involved. @Thorsten: any help here would be appreciated - should the following pam_apparmor postun script be changed to handle the -pc link removal (and divergence)?

(In reply to David Disseldorp from comment #2)
...
>   %postun -n pam_apparmor
>   pam-config -d --apparmor
>   pam-config --update

(In reply to David Disseldorp from comment #2)
> Thanks for the report. On the apparmor side there haven't been any recent
> changes in this area that I'm aware of. The postun script carries:
>   %postun -n pam_apparmor
>   pam-config -d --apparmor
>   pam-config --update

That's of course wrong, %postun is called on every update, too.

if [ $1 -eq 0 ]; then
        pam-config --delete --apparmor || :
fi

would be correct. The "--update" should not be called at all.

(In reply to David Disseldorp from comment #6)

> Which would indicate that a user or utility attempted to manually configure
> more cautious/restrictive PAM behaviour. @Martin: do you know who / what is
> responsible for the pam configuration changes above?

None of the diff changes are supported by pam-config. So replace /etc/pam.d/common-* symlinks with real files is correct. 

> We provide (relatively old) documentation which instructs users to remove
> the -pc symlink when manually changing the PAM configuration:
> https://www.suse.com/support/kb/doc/?id=000018934 so it looks like this kind
> of divergence should be acceptable.

Current instructions how to do that are in the header of every common-*-pc file. The kb article looks still correct.

> > As a workaround it seems that the links can be restored by using the --force
> > option, e.g. "pam-config --update --force". However, to properly resolve
> > this issue we'll need to find out what's responsible for causing the
> > unexpected link state.

That's not a workaround, since you are breaking the existing configuration.

> I think I'll need to get someone with more PAM knowledge involved.
> @Thorsten: any help here would be appreciated - should the following
> pam_apparmor postun script be changed to handle the -pc link removal (and
> divergence)?

NO!

As the header of common-*-pc and the kb article says, it's ok and correct to replace the symlinks with your own files if you want to do changes to the common-* files, which are not supported by pam-config.
Afterwards, you __cannot__ manage the common-* files anymore with pam-config, this is expected and correct behavior.

If you don't want that pam-config get's disabled, find the package or admin which disabled pam-config.
The result of openQA on this setup when installing/updating pam_apparmor is expected, correct and no bug.

the hardened images have their pam config postprocessed by the hardening script.

here it is 
/usr/share/scap-security-guide/bash/sle15-script-pcs-hardening.sh
from scap-security-guide AFAIK

Thanks for the details, Thorsten...

(In reply to Thorsten Kukuk from comment #8)
> (In reply to David Disseldorp from comment #6)
> 
> > Which would indicate that a user or utility attempted to manually configure
> > more cautious/restrictive PAM behaviour. @Martin: do you know who / what is
> > responsible for the pam configuration changes above?
> 
> None of the diff changes are supported by pam-config. So replace
> /etc/pam.d/common-* symlinks with real files is correct. 
> 
> > We provide (relatively old) documentation which instructs users to remove
> > the -pc symlink when manually changing the PAM configuration:
> > https://www.suse.com/support/kb/doc/?id=000018934 so it looks like this kind
> > of divergence should be acceptable.
> 
> Current instructions how to do that are in the header of every common-*-pc
> file. The kb article looks still correct.
> 
> > > As a workaround it seems that the links can be restored by using the --force
> > > option, e.g. "pam-config --update --force". However, to properly resolve
> > > this issue we'll need to find out what's responsible for causing the
> > > unexpected link state.
> 
> That's not a workaround, since you are breaking the existing configuration.

Ack.

> > I think I'll need to get someone with more PAM knowledge involved.
> > @Thorsten: any help here would be appreciated - should the following
> > pam_apparmor postun script be changed to handle the -pc link removal (and
> > divergence)?
> 
> NO!
> 
> As the header of common-*-pc and the kb article says, it's ok and correct to
> replace the symlinks with your own files if you want to do changes to the
> common-* files, which are not supported by pam-config.
> Afterwards, you __cannot__ manage the common-* files anymore with
> pam-config, this is expected and correct behavior.

Understood. I'll proceed with the change that you proposed in comment#7, which I assume should also be reflected in the pam-config --add call. I.e.

--- apparmor.spec       (revision 05212f487d17be490f81b95912f117d2)
+++ apparmor.spec       (working copy)
@@ -760,12 +760,14 @@
 %if %{with pam}
 
 %post -n pam_apparmor
-pam-config -a --apparmor
-pam-config --update
+if [ $1 -eq 1 ]; then
+        pam-config --add --apparmor || :
+fi
 
 %postun -n pam_apparmor
-pam-config -d --apparmor
-pam-config --update
+if [ $1 -eq 0 ]; then
+        pam-config --delete --apparmor || :
+fi
 %endif

Does this look reasonable?

(In reply to David Disseldorp from comment #10)
...
> Understood. I'll proceed with the change that you proposed in comment#7,
> which I assume should also be reflected in the pam-config --add call. I.e.
> 
> --- apparmor.spec       (revision 05212f487d17be490f81b95912f117d2)
> +++ apparmor.spec       (working copy)
> @@ -760,12 +760,14 @@
>  %if %{with pam}
>  
>  %post -n pam_apparmor
> -pam-config -a --apparmor
> -pam-config --update
> +if [ $1 -eq 1 ]; then
> +        pam-config --add --apparmor || :
> +fi
>  
>  %postun -n pam_apparmor
> -pam-config -d --apparmor
> -pam-config --update
> +if [ $1 -eq 0 ]; then
> +        pam-config --delete --apparmor || :
> +fi
>  %endif
> 
> Does this look reasonable?

https://build.opensuse.org/request/show/1113476

This is an autogenerated message for OBS integration:
This bug (1215596) was mentioned in
https://build.opensuse.org/request/show/1113527 Factory / apparmor

(In reply to OBSbugzilla Bot from comment #12)
> This is an autogenerated message for OBS integration:
> This bug (1215596) was mentioned in
> https://build.opensuse.org/request/show/1113527 Factory / apparmor

@Martin: could you please confirm that this fixes the openQA test failure? A 15sp5 repository with this change is available at:

https://download.suse.de/ibs/home:/dmdiss:/bsc1215596_pam_aa_post/standard/

(In reply to David Disseldorp from comment #13)
> (In reply to OBSbugzilla Bot from comment #12)
> > This is an autogenerated message for OBS integration:
> > This bug (1215596) was mentioned in
> > https://build.opensuse.org/request/show/1113527 Factory / apparmor
> 
> @Martin: could you please confirm that this fixes the openQA test failure? A
> 15sp5 repository with this change is available at:
> 
> https://download.suse.de/ibs/home:/dmdiss:/bsc1215596_pam_aa_post/standard/

It is a bit complicate to test it in Azure as we do not have direct access to internal SUSE network.

I have tried to copy the package and update it directly on the running system.

```
azureuser@openqa-suse-de-f6438e4597f55ca5:~> sudo rpm -Uvh pam_apparmor-3.0.4-150500.11.9.1.x86_64.rpm
warning: pam_apparmor-3.0.4-150500.11.9.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID ce3b672e: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...
   1:pam_apparmor-3.0.4-150500.11.9.1 ################################# [ 50%]
Cleaning up / removing...
   2:pam_apparmor-3.0.4-150500.11.3.1 ################################# [100%]
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
File /etc/pam.d/common-account is no symlink to common-account-pc.
New config from common-account-pc is not in use!
File /etc/pam.d/common-auth is no symlink to common-auth-pc.
New config from common-auth-pc is not in use!
File /etc/pam.d/common-password is no symlink to common-password-pc.
New config from common-password-pc is not in use!
File /etc/pam.d/common-session is no symlink to common-session-pc.
New config from common-session-pc is not in use!
warning: %postun(pam_apparmor-3.0.4-150500.11.3.1.x86_64) scriptlet failed, exit status 1
```

(In reply to Martin Loviska from comment #14)

> It is a bit complicate to test it in Azure as we do not have direct access
> to internal SUSE network.
> 
> I have tried to copy the package and update it directly on the running
> system.

Since the installed package has the broken %postun, there is no way to fix the RPM postun script error for the first update. Only the second update should not throw the RPM error anymore.

(In reply to Thorsten Kukuk from comment #15)
> 
> Since the installed package has the broken %postun, there is no way to fix
> the RPM postun script error for the first update. Only the second update
> should not throw the RPM error anymore.

That is fine for us, at least we will be aware when the incident tests will fail with new package as we need to manually approve the incident request.

(In reply to Martin Loviska from comment #16)
> (In reply to Thorsten Kukuk from comment #15)
> > 
> > Since the installed package has the broken %postun, there is no way to fix
> > the RPM postun script error for the first update. Only the second update
> > should not throw the RPM error anymore.
> 
> That is fine for us, at least we will be aware when the incident tests will
> fail with new package as we need to manually approve the incident request.

Thanks Thorsten and Martin. I'll go ahead and backport+submit the (now in Factory) fix against the SLE maintenance packages.

SUSE-RU-2023:4003-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1215596
Sources used:
openSUSE Leap 15.5 (src): apparmor-3.0.4-150500.11.9.1, libapparmor-3.0.4-150500.11.9.1
SUSE Linux Enterprise Micro 5.5 (src): apparmor-3.0.4-150500.11.9.1, libapparmor-3.0.4-150500.11.9.1
Basesystem Module 15-SP5 (src): apparmor-3.0.4-150500.11.9.1, libapparmor-3.0.4-150500.11.9.1
Development Tools Module 15-SP5 (src): apparmor-3.0.4-150500.11.9.1
Server Applications Module 15-SP5 (src): apparmor-3.0.4-150500.11.9.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.