On Sun, 14 Feb 2010, Aurelien Jarno wrote:
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.
Any progress on this? All of my clients/servers are still in a funky
state because I can't run any updates on them since updating glibc will
break authentication on all of them.
And again, thank you for looking into this.
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
aurel...@aurel32.net http://www.aurel32.net
