[Pkg-samba-maint] Bug#647430: Bug#647430: Bug#647430: Bug#647429: libpam-smbpass: prerm is not multiarch-safe

[Ivo De Decker]

Steve,

On Tue, Jul 31, 2012 at 09:36:34AM -0700, Steve Langasek wrote:
> On Tue, Jul 31, 2012 at 11:43:43PM +0800, Frank Chung wrote:
> 
> > I must confess that I'm not a regular Debian contributor, just a grateful
> > user of libpam-winbind who would like to help out (thanks maintainers!).
> > There may be perfectly good reasons why libpam-winbind (and libpam-smbpass)
> > is currently one package that I'm ignorant of.
> 
> Because splitting packages into tiny packages carries a cost in terms of
> Packages downloads, maintenance, and system understandability.
> 
> This is a general problem of multiarch: same packages with maintainer
> scripts; I'd like for us to find a better solution than further splitting of
> packages.  But if all else fails, yes, we can split them for wheezy.

While it is true that maintainer scripts are (in some cases) a gerenal problem
of multiarch, the problem with pam is more specific. I don't think splitting
the package really solves this problem.

Imagine a system with an amd64 sshd and a i386 telnetd.

When both libpam-smbpass:i386 and libpam-smbpass:amd64 are installed, there is
no problem. The module should be active.
When neither are installed. There is no problem either. The module should not
be active.

But when one (say amd64) is installed, and the other (i386) isn't. What should
the config be? There is no 'correct' config: if the module is enabled, it will
be used for sshd, but not for telnetd, which will log an error when someone
tries to log in. The obvious solution is to enable it anyway. For
architectures where the module is not installed, it will just be ignored
(which gives the same result as not enabling it).

This lead back to the original question in the bug reports: find a way to
enable the pam module whenever it is installed for at least one arch, and
disable it only when it is not installed for any architecture.

Installing already does the right thing (it will always enable the module).
Uninstalling will currently always disable the module, even if an installation
remains for other a different architecture.

The pam-auth-update manpage says:

"--remove profile [profile...]
Remove the specified profiles from the system configuration. pam-auth-update
--remove should be used to remove profiles from the configuration before the
modules they reference are removed from disk, to ensure that PAM is in a
consistent and usable state at all times during package upgrades or removals."

It's not clear to me what this 'consistent and usable state' means. If the
remove is done in the postrm, there will be a period where there module is not
installed, but it is still enabled. If this is problematic, then the situation
above (with amd64 installed and i386 not) is just as problematic.

If it is acceptable to have a period where the module is enabled in the
config, but no longer installed, the solution to this bug might be to do
remove the
pam-auth-update --remove
from the prerm script and add
pam-auth-update --package
in the postrm, which will enable the module if /usr/share/pam-configs/(module
config file) exists. This will be the case if the module is installed for at
least one architecture. In other cases, this will disable the module.

Is this an acceptable solution?

Cheers,

Ivo