Bug#723050: can't log in
¡Hola Mathieu! El 2013-11-21 a las 22:04 +0100, Mathieu MD escribió: I was trying to follow the code, and it looks like /usr/lib/kde4/libexec/kcheckpass uses the kdm pam service, which imports the common services and adds some normal pam stuff. :: Ups, sorry, that was wrong, it uses the /etc/pam.d/other pam service. I tried to run xscreensaver as you told, but it did not change anything: I still cannot login back. @include common-auth @include common-account I don't know if the problem is still reproduceable for you, it was never reproduceable for me. But if you do, could you check the permissions of the /sbin/unix_chkpwd command? -- Don't let what you cannot do interfere with what you can do. -- Wooden's Rule Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#723050: can't log in
Hello Maximiliano, Thanks for still being around my bug report :-) I don't know if the problem is still reproduceable for you, it was never reproduceable for me. I am still using the same machine, and though up-to-date, this bug is still here. :( But if you do, could you check the permissions of the /sbin/unix_chkpwd command? Permissions on unix_chkpwd seems to be correct with setgid shadow: -rwxr-sr-x 1 root shadow 35K 02-14 00:27 /sbin/unix_chkpwd* it uses the /etc/pam.d/other pam service. And here is my /etc/pam.d/other: # # # /etc/pam.d/other - specify the PAM fallback behaviour # # Note that this file is used for any unspecified service; for example #if /etc/pam.d/cron specifies no session modules but cron calls #pam_open_session, the session module out of /etc/pam.d/other is #used. If you really want nothing to happen then use pam_permit.so or #pam_deny.so as appropriate. # We fall back to the system default in /etc/pam.d/common-* # @include common-auth @include common-account @include common-password @include common-session # Thank you. -- Mathieu -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5335bb95.6010...@gmail.com
Bug#723050: can't log in
¡Hola Mathieu! El 2014-03-28 a las 19:12 +0100, Mathieu MD escribió: But if you do, could you check the permissions of the /sbin/unix_chkpwd command? Permissions on unix_chkpwd seems to be correct with setgid shadow: -rwxr-sr-x 1 root shadow 35K 02-14 00:27 /sbin/unix_chkpwd* And the password of your user is in /etc/shadow which is readable by the shadow group? It might be interesting to know if /sbin/unix_chkpwd is being called at all, using second session and strace you can check this, so you lock your screen and from another session, you'll need to find the pid of your screensaver, it can be kscreensaver, xscreensaver, or in my case plasma_overlay, then: $ strace -vfp $pid_of_screensaver -e execve Try to unlock the screensaver and check the logged output. The output shouldn't be more than 30 lines, if it's more, redirect it into a file and attach the file here. -- La duración de un minuto depende de que lado del baño estés. -- Ley de la Relatividad (Burke) Saludos /\/\ /\ `/ signature.asc Description: Digital signature
Bug#723050: can't log in
Muchas gracias Maximiliano! It was the permissions on /etc/shadow which were root:root 600. Fixing them to root:shadow 640 made both xscreensaver and kscreensaver able to log me back in! I have no idea what may have changed permissions on shadow file, though. Anyway, thank you very much for your help! :-) -- Mathieu Le 28/03/2014 20:25, Maximiliano Curia a écrit : ¡Hola Mathieu! El 2014-03-28 a las 19:12 +0100, Mathieu MD escribió: But if you do, could you check the permissions of the /sbin/unix_chkpwd command? Permissions on unix_chkpwd seems to be correct with setgid shadow: -rwxr-sr-x 1 root shadow 35K 02-14 00:27 /sbin/unix_chkpwd* And the password of your user is in /etc/shadow which is readable by the shadow group? It might be interesting to know if /sbin/unix_chkpwd is being called at all, using second session and strace you can check this, so you lock your screen and from another session, you'll need to find the pid of your screensaver, it can be kscreensaver, xscreensaver, or in my case plasma_overlay, then: $ strace -vfp $pid_of_screensaver -e execve Try to unlock the screensaver and check the logged output. The output shouldn't be more than 30 lines, if it's more, redirect it into a file and attach the file here. -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5335fdcd.3040...@gmail.com
Bug#723050: can't log in
Hi Maximiliano, I do use kdm to login. I tried to run xscreensaver as you told, but it did not change anything: I still cannot login back. Here is my pam files: # # /etc/pam.d/kdm - specify the PAM behaviour of kdm # auth required pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale @include common-auth sessionrequired pam_limits.so @include common-account @include common-password @include common-session Where it's missing SELinux (which is not installed) and pam_loginuid.so lines, comparing to yours, and you don't have common-session. I tried adding the pam_loginuid.so, but it didn't helped. # # /etc/pam.d/xscreensaver - PAM behavior for xscreensaver # @include common-auth @include common-account Thanks for trying! -- Mathieu Le 15/11/2013 15:02, Maximiliano Curia a écrit : Hi, In article 52433f8a.3040...@gmail.com you wrote: Thanks for your feedback. It may have been the case the very first day, but now that I had reboot many times, and still the problem is the same, what could it be? (sorry for replying late: I did not received your message) I was trying to follow the code, and it looks like /usr/lib/kde4/libexec/kcheckpass uses the kdm pam service, which imports the common services and adds some normal pam stuff. :: auth required pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale @include common-auth # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without out this it is possible # that a module could execute code in the wrong domain. session[success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close sessionrequired pam_limits.so sessionrequired pam_loginuid.so @include common-session # SELinux needs to intervene at login time to ensure that the process # starts in the proper default security context. Only sessions which are # intended to run in the user's context should be run after this. session[success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open @include common-account @include common-password Which is fine for a starting session. But, this is different from what xscreensaver uses, which is only the common-auth and common-account. :: @include common-auth @include common-account Also, you could be using KDE without having kdm installed, which would load the other pam service file. :: @include common-auth @include common-account @include common-password @include common-session So, I'm still not sure if this could be the cause of this issue, but I'll need to know what pam modules you have enabled. And if you replace kscreensaver with xscreensaver (run xscreensaver, settings, restart daemon, lock screen) if you can unlock you session or not. Thanks, -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/528e7545.7050...@gmail.com
Bug#723050: can't log in
Hi, In article 52433f8a.3040...@gmail.com you wrote: Thanks for your feedback. It may have been the case the very first day, but now that I had reboot many times, and still the problem is the same, what could it be? (sorry for replying late: I did not received your message) I was trying to follow the code, and it looks like /usr/lib/kde4/libexec/kcheckpass uses the kdm pam service, which imports the common services and adds some normal pam stuff. :: auth required pam_nologin.so auth required pam_env.so readenv=1 auth required pam_env.so readenv=1 envfile=/etc/default/locale @include common-auth # SELinux needs to be the first session rule. This ensures that any # lingering context has been cleared. Without out this it is possible # that a module could execute code in the wrong domain. session[success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so close sessionrequired pam_limits.so sessionrequired pam_loginuid.so @include common-session # SELinux needs to intervene at login time to ensure that the process # starts in the proper default security context. Only sessions which are # intended to run in the user's context should be run after this. session[success=ok ignore=ignore module_unknown=ignore default=bad] pam_selinux.so open @include common-account @include common-password Which is fine for a starting session. But, this is different from what xscreensaver uses, which is only the common-auth and common-account. :: @include common-auth @include common-account Also, you could be using KDE without having kdm installed, which would load the other pam service file. :: @include common-auth @include common-account @include common-password @include common-session So, I'm still not sure if this could be the cause of this issue, but I'll need to know what pam modules you have enabled. And if you replace kscreensaver with xscreensaver (run xscreensaver, settings, restart daemon, lock screen) if you can unlock you session or not. Thanks, -- Porque no respeta el orden natural en el que se leen las cosas ¿Por qué contestar al principio del mensaje es malo? Saludos /\/\ /\ `/ -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131115140250.ga30...@gnuservers.com.ar
Bug#723050: can't log in
Thanks for your feedback. It may have been the case the very first day, but now that I had reboot many times, and still the problem is the same, what could it be? (sorry for replying late: I did not received your message) -- Mathieu I see you also pulled in the libc and pam updates. During the libc upgrade there should have been a dialog requesting service restarts for ssh and cupsd as the upgrade breaks authentication. The wall of text explaining the upgrade should have stated that X (and therefore kdm) needs to be restarted manually after the upgrade, as restarting X logs out any active sessions and would therefore kill the upgrade. ssh works because it can be restarted safely. This happens every time libc and pam are updated and is due to a limitation in pam. TLDR; Any time you upgrade libc or pam, you /must/ log out and restart kdm. /not maintainer -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52433f8a.3040...@gmail.com
Bug#723050: can't log in
I see you also pulled in the libc and pam updates. During the libc upgrade there should have been a dialog requesting service restarts for ssh and cupsd as the upgrade breaks authentication. The wall of text explaining the upgrade should have stated that X (and therefore kdm) needs to be restarted manually after the upgrade, as restarting X logs out any active sessions and would therefore kill the upgrade. ssh works because it can be restarted safely. This happens every time libc and pam are updated and is due to a limitation in pam. TLDR; Any time you upgrade libc or pam, you /must/ log out and restart kdm. /not maintainer -- To UNSUBSCRIBE, email to debian-qt-kde-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130920015451.3...@web006.roc2.bluetie.com
