Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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
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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-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
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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? Thanks, and please let me know if I can do anything to help. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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. Thank you 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
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 >>> aurel...@aurel32.net http://www.aurel32.net >>> > > > -- Aurelien Jarno
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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. Thank you! 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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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? - 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? - Are you using nscd on the clients? - What the result of "getent passwd a_nis_user" on a client when running as a standard (local) user, a root user, for both - Do you have more info the client system logs? -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#566844: libc6 causing "Authentication service cannot retrieve authentication info"
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. 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. 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? And yes, if I create local accounts directly on the system itself, there are no problems, it's just the NIS accounts (again, I'm guessing because there is no shadow entries) that are causing me problems. Please let me know if you need any further information from me. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.ISO-8859-15, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.3.2-1.1 GCC support library libc6 recommends no packages. Versions of packages libc6 suggests: pn glibc-doc (no description available) ii locales 2.7-18 GNU C Library: National Language ( -- debconf information: glibc/upgrade: true glibc/restart-failed: glibc/restart-services: -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
