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

Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"



On Sat, Feb 13, 2010 at 06:22:17PM -0500, root wrote:
> On Sat, 13 Feb 2010, Aurelien Jarno wrote:
>
>> On Fri, Feb 12, 2010 at 09:21:59AM -0500, root wrote:
>>> On Fri, 12 Feb 2010, Aurelien Jarno wrote:
>>>
>>>> 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.
>>>
>>> Well, I decided to do some searching around in hopes of coming up with
>>> some new ideas. I've never used adjunct passwords before, so I never
>>> really knew what they were.  After doing some research online, do adjunct
>>> passwords mean that you put a "##username" in the passwd file for each of
>>> the users?  If so, I think that might be the problem.  We use a custom
>>> PAM authentication module that we wrote to do a special type of kerberos
>>> authentication.  And our passwd file contains the special kerberos
>>> principal in the "password field", so for instance, our users would have
>>> passwd entries like this:
>>>   username1:##ABC12:123:100:Name:/home/dir1:/bin/tcsh
>>>   username2:##CAB21:124:100:Name:/home/dir2:/bin/tcsh
>>>   username3:##I#XYZ12:125:100:Name:/home/dir3:/bin/tcsh
>>>   username4:##E#ZYX21:125:100:Name:/home/dir4:/bin/tcsh
>>> We use the "##" to determine whether or not we should use our
>>> authentication module or not.  Is the new libc6 just looking for the "##"
>>> in the beginning and using that to determine whether or not the passwd
>>> file is using adjunct passwords or not?  If so, is there any other way to
>>> determine adjunct passwords because I'm guessing that, that must be
>>> causing the problem.  In other words, the new libc6 is seeing our special
>>> password entries and simply removing them.
>>>
>>
>> Yes, the new glibc only looks for the "##" at the beginning of the
>> passwd entry to detect the adjunct passwords. Actually this part hasn't
>> changed in the new glibc, it's only the corresponding action that has
>> changed. Before it was doing a new query to the NIS server to get the
>> adjunct password and merge it. With the new version merges a 'x'
>> instead, as the real merge is now done in the shadow part.
>>
>> So even before it seems your system was doing a lot of useless NIS
>> requests to the server, even though it harms less than in the current
>> status.
>>
>> I will look if the adjunct password detection can be improved.
>
> Like I said, I don't know much about how adjunct passwords work, or the  
> underlying authentication system itself, but could you just leave the ## 
> entry there instead of putting the "x" in there?  Or would that cause 
> problems?  I completely understand why the actual password would be put 
> in the shadow part, but would it hurt to just leave the ## entry there in 
> the password field?
>

Yes, that would hurt, as it would try to match the password with this
entry instead of the shadow one.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net



Reply to: