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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100214140611.gg20...@hall.aurel32.net
