Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
root a écrit :
> Is more information needed from me? Or is there anything I can do to
> expedite this bug fix? I've got 138 machines in an unstable state because
> I can't do updates on them because of this libc6 issue. If there is
> anything that I can do, please let me know.
>
I have to say I am out of idea. I am only able to reproduce the
behaviour you observed when using adjunct passwords (this is actually
what the security issue fixed), but at the same time you told me you are
not using adjunct passwords.
>
> On Wed, 27 Jan 2010, root wrote:
>
>> On Mon, 25 Jan 2010, Aurelien Jarno wrote:
>>
>>> On Mon, Jan 25, 2010 at 09:08:08AM -0500, root wrote:
>>>> Package: libc6
>>>> Version: 2.7-18
>>>> Severity: critical
>>>> Justification: breaks unrelated software
>>>>
>>>>
>>>> I'm running Debian Lenny with a stock 2.6.26-2 AMD64 kernel, and after
>>>> upgrading any of my systems to use the latest libc6 package from
>>>> debian-security (2.7-18lenny2), all of my systems that use NIS can no
>>>> longer authenticate. All I get is "Authentication service cannot retrieve
>>>> authentication info". If I upgrade a system to 2.7-18lenny2, I
>>>> immediately start having problems, and as soon as I revert back to 2.7-18,
>>>> everything works perfectly. I've been using the same NIS setup for close
>>>> to 5 years now, and have been moving it along from Sarge, to Etch, to
>>>> Lenny without any problems...until now.
>>> I am sorry about that. This security update was there to prevent leaking
>>> adjunct passwords to normal users.
>>>
>>>> My /etc/nsswitch.conf:
>>>> passwd: compat
>>>> group: compat
>>>> shadow: compat
>>>>
>>>> Like I said, I am using NIS, however both the NIS master server and the
>>>> NIS clients both break when I upgrade libc6 to 2.7-18lenny2. The NIS
>>>> server is again, a stock Debian Lenny server. With the NIS server, I am
>>>> combining the passwd/shadow files on the NIS server into just the passwd
>>>> map (using the MERGE_PASSWD option). So the NIS clients don't actually
>>>> see any shadow file entries for any of the NIS accounts.
>>> Ok, so users were able to login even if there was no shadow entry.
>>>
>>>> I've also tried changing the nsswitch.conf file to:
>>>> passwd: nis files
>>>> group: nis files
>>>> shadow: files
>>>>
>>>> You'll notice I left the "nis" option off of the shadow entry, since
>>>> there's no need for it, since there's no "shadow" map. My guess is that,
>>>> this is the cause of the problem...In other words, because the system
>>>> isn't seeing shadow entries, it's bailing out. But why all of a sudden
>>>> did this break in the latest libc6? And is there a way to get the old
>>>> functionality back?
>>> What the changes did is to stop merging adjunct passwords to the passwd
>>> database, and merge them in the shadow database instead. There is no new
>>> requirement for shadow entries.
>>>
>>> If you are not using adjunct password, no changes should have happened
>>> for you. As it doesn't work, it seems something has broken, we have to
>>> understand why. FYI, I have just done a NIS setup using the MERGE_PASSWD
>>> option, and only compat entries into /etc/nsswitch.conf, and I don't see
>>> this problem.
>>>
>>> I will need more informations to debug this:
>>> - Are you using adjunct passwords in addition to merged passwords?
>> No.
>>
>>> - As I understand, you have upgraded libc6 on both the NIS server and
>>> the clients. Can you please try to see if it also breaks if you
>>> upgrade only the clients?
>> Yes it still breaks, when I upgrade just one of the clients.
>>
>>> - Are you using nscd on the clients?
>> No.
>>
>>> - What the result of "getent passwd a_nis_user" on a client when running
>>> as a standard (local) user, a root user, for both
>> Very interesting... Whether I run the "getent" command as root or a normal
>> user, I get the following:
>> On the libc6 (2.7-18) system:
>> username:encrypted_passwd_here:123456:654321:MyName:/my/home/directory:/bin/tcsh
>>
>> On the libc6 (2.7-18lenny2) system:
>> username:x:123456:654321:MyName:/my/home/directory:/bin/tcsh
>>
>> That does seem to be what is causing my problems...
>>
>>> - Do you have more info the client system logs?
>> Not really, the only thing I see is just:
>> Jan 27 06:53:45 hostname su[31991]: pam_authenticate: Authentication service
>> cannot retrieve authentication info
>> Jan 27 06:53:45 hostname su[31991]: FAILED su for testuser2 by testuser1
>> Jan 27 06:53:45 hostname su[31991]: - pts/1 testuser1:testuser2
>>
>> If you know of any way of getting more debug info from PAM, let me know and
>> I'll run more tests.
>>
>> By the way, thank you for your help, I really appreciate it!
>>
>>
>>> --
>>> Aurelien Jarno GPG: 1024D/F1BCDB73
>>> aurelien@aurel32.net http://www.aurel32.net
>>>
>
>
>
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
Reply to: