[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#656352: marked as done (pu: package libpam-krb5/4.3-1squeeze1)

Your message dated Thu, 19 Jan 2012 11:17:16 +0100
with message-id <20120119101716.GA9941@thrall.0x539.de>
and subject line Re: Bug#656352: pu: package libpam-krb5/4.3-1squeeze1
has caused the Debian Bug report #656352,
regarding pu: package libpam-krb5/4.3-1squeeze1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
656352: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656352
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: pu

Filing this in advance of actually doing the update work....

libpam-krb5 4.4-3 in unstable added the following change (from
NEWS.Debian):

  The default PAM configuration for the password stack changed in this
  version to skip all other modules if the Kerberos password change
  succeeded.  This works better and with fewer strange errors for the
  common case of Kerberos accounts not having a local password.

  If you want to instead synchronize your local and Kerberos passwords,
  you will need to not manage the module with pam-auth-update and instead
  manually configure the password stack to run both pam_krb5 and pam_unix.
  See /usr/share/doc/libpam-krb5/README.Debian.gz for more details.

Without this change, users of the module where accounts are only in
Kerberos and some external user source like LDAP and don't occur in
/etc/shadow were unable to use it to change Kerberos passwords, because
pam_unix would reject the password change due to the missing /etc/shadow
entry.  The change is basically a single line in the pam-configs
configuration:

--- a/debian/pam-auth-update
+++ b/debian/pam-auth-update
@@ -12,9 +12,9 @@ Account:
        required                        pam_krb5.so minimum_uid=1000
 Password-Type: Primary
 Password:
-       requisite                       pam_krb5.so minimum_uid=1000 try_first_pass use_authtok
+       [success=end default=ignore]    pam_krb5.so minimum_uid=1000 try_first_pass use_authtok
 Password-Initial:
-       requisite                       pam_krb5.so minimum_uid=1000
+       [success=end default=ignore]    pam_krb5.so minimum_uid=1000
 Session-Type: Additional
 Session:
        optional                        pam_krb5.so minimum_uid=1000

However, it's not backward-compatible.  If one was relying on the previous
behavior, this change will require switching away from the defaults.

Petter Reinholdtsen from DebianEdu requested this change make it into
stable as well, since it's causing problems for them (they set up accounts
in Kerberos and LDAP only by default).

What do the stable release managers think?  Is this something that would
be reasonable to do in stable?  I think it does improve the package for
the majority use case, but it's a larger change in configuration than I
would normally propose for a stable update.

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

--- End Message ---
--- Begin Message --- 
Hi Russ,

On Wed, Jan 18, 2012 at 09:54:19AM -0800, Russ Allbery wrote:
> However, it's not backward-compatible.  If one was relying on the previous
> behavior, this change will require switching away from the defaults.

I acknowledge that the behaviour is pretty much annoying.  However I think that
stable is not the place to make such a change.  It's unfortunate that it went
into stable unnoticed, but while fixing bugs is appreciated, behaviour changes
are very much frowned upon, especially in authentication modules.

A Debconf note upon upgrade wouldn't help for automated installs that want
mostly reproducible behaviour (apart from security updates) for stable installs
and it would also need to have a very high priority to be shown everywhere upon
upgrade.  I wouldn't like to introduce that in stable.

Kind regards, thanks for contacting us and sorry,
Philipp Kern
-- 
 .''`.  Philipp Kern                        Debian Developer
: :' :  http://philkern.de                         Stable Release Manager
`. `'   xmpp:phil@0x539.de                         Wanna-Build Admin
  `-    finger pkern/key@db.debian.org

Attachment: signature.asc
Description: Digital signature


--- End Message ---
Reply to: