Bug 337470 - Plasma 5 unable to unlock session
Summary: Plasma 5 unable to unlock session
Status: RESOLVED DOWNSTREAM
Alias: None
Product: kscreensaver
Classification: Miscellaneous
Component: locker-qml (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR major
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-15 16:58 UTC by vaniaz
Modified: 2015-10-23 11:09 UTC (History)
9 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vaniaz 2014-07-15 16:58:37 UTC
Can't unlock session after locking it after updating to plasma 5. I'm using latest opensuse rpms and default locker.
Comment 1 Olaf Bonorden 2014-07-21 08:50:27 UTC
Same here.
Comment 2 Hrvoje Senjan 2014-07-21 22:00:39 UTC
which login manager do you use? on openSUSE we pass -DKDE4_COMMON_PAM_SERVICE=xdm, so xdm is required (also is a packaging bug that xdm is not hard-dep for plasma5-workspace package)
Comment 3 vaniaz 2014-07-22 07:23:08 UTC
Yast's sysconfig editor shows, that DISPLAYMANAGER="kdm"
Comment 4 vaniaz 2014-07-22 07:33:46 UTC
I tried xdm. No result.
Comment 5 Elias Probst 2014-08-28 01:14:55 UTC
Please check if the file /etc/pam.d/kde exists on your system with the following content:

#%PAM-1.0
auth        required    pam_unix.so nullok
account     include     system-auth
password    include     system-auth
session     include     system-auth

If it doesn't, please test + report whether creating it fixes the problem for you.
Instead of locking yourself out of your session, you can also verify this more easily using `kcheckpass` on the commandline.
Comment 6 vaniaz 2014-08-29 10:21:52 UTC
There was no such file. I created it, still could not unlock. kcheckpass does not exist in my system nor I could find it in zypper. I am using opensuse rpms.
Comment 7 Hrvoje Senjan 2014-08-29 19:47:57 UTC
the path in openSUSE packages is /usr/lib(64)/libexec/kcheckpass. and /etc/pam.d/kde won't help, as we use /etc/pam.d/xdm, as mentioned in comment 2.
but please report back after manually checking with kcheckpass
Comment 8 vaniaz 2014-08-30 10:40:50 UTC
 /usr/lib64/libexec/kcheckpass 
Password: 
Information: Permissions on the password database may be too restrictive.
Authentication failure
Comment 9 Hrvoje Senjan 2014-08-31 20:07:58 UTC
that comes from PAM; can you paste output of:
grep PERMISSION_SECURITY /etc/sysconfig/security
Comment 10 vaniaz 2014-09-03 06:28:09 UTC
grep PERMISSION_SECURITY /etc/sysconfig/security
PERMISSION_SECURITY="easy local"
# PERMISSION_SECURITY. If PERMISSION_SECURITY contains 'secure' or
Comment 11 Marcus Furlong 2014-09-13 09:37:42 UTC
The problem seems to be with the permissions on /etc/shadow

chmod o+r /etc/shadow fixes the above issue, however this file should not be world readable
Comment 12 Kyle Mills 2014-11-25 23:40:49 UTC
Alternatively, chmod +s /usr/lib64/libexec/kcheckpass temporarily fixes it until plasma5-workspace is reinstalled.
Comment 13 Martin Flöser 2015-01-23 11:33:55 UTC
sorry, seams to be a distro issue. Especially comment #12 shows this:
install(CODE "
    set(KCP_PATH \"\$ENV{DESTDIR}${LIBEXEC_INSTALL_DIR}/kcheckpass\")
    execute_process(COMMAND sh -c \"chown root '\${KCP_PATH}' && chmod +s '\${KCP_PATH}'\")
")

kcheckpass is still chown to root and made suid. If distros don't do that they should ensure that kcheckpass can interact with PAM (that works fine for example on Debian).
Comment 14 Mircea Kitsune 2015-10-22 19:37:11 UTC
I got this as well after a distribution upgrade (openSUSE 13.2 -> openSUSE Tumbleweed), also switching from KDE4 to Plasma 5. /usr/lib64/libexec/kcheckpass reported the same access denied error, and chmod +s /usr/lib64/libexec/kcheckpass indeed fixed the problem for now. Although this is marked as resolved, the issue happened today with the latest Tumbleweed repository, which tells me that something nasty is still up.
Comment 15 squan 2015-10-22 19:54:31 UTC
(In reply to Mircea Kitsune from comment #14)
> I got this as well after a distribution upgrade (openSUSE 13.2 -> openSUSE
> Tumbleweed), also switching from KDE4 to Plasma 5.
> /usr/lib64/libexec/kcheckpass reported the same access denied error, and
> chmod +s /usr/lib64/libexec/kcheckpass indeed fixed the problem for now.
> Although this is marked as resolved, the issue happened today with the
> latest Tumbleweed repository, which tells me that something nasty is still
> up.

This happens to me after updating (zypper up) after which /etc/shadow regresses  to read-only. Really nasty experience.  The workaround is to switch to text console with Shift Strg F1, login, fix the password shadow file as described in comment #11 and then switch back to KDE session with Strg F7 (sometimes F6).
Comment 16 Martin Flöser 2015-10-23 05:59:41 UTC
(In reply to Mircea Kitsune from comment #14)
> Although this is marked as resolved, the issue happened today with the
> latest Tumbleweed repository, which tells me that something nasty is still
> up.

Please report this to the openSUSE developers to fix this. It's nothing we at KDE can do about. We only provide software which gets distributed by e.g. openSUSE. Such integration problems need to be addressed by the distribution.
Comment 17 Wolfgang Bauer 2015-10-23 08:41:05 UTC
(In reply to Martin Gräßlin from comment #16)
> (In reply to Mircea Kitsune from comment #14)
> > Although this is marked as resolved, the issue happened today with the
> > latest Tumbleweed repository, which tells me that something nasty is still
> > up.
> 
> Please report this to the openSUSE developers to fix this. It's nothing we
> at KDE can do about. We only provide software which gets distributed by e.g.
> openSUSE. Such integration problems need to be addressed by the distribution.

It is known to openSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=931296

And it's only a problem for systems that have been upgraded since years (before 12.3 which came out March 2013), because the PAM config is not modified automatically. On fresh installations (or systems originally installed with openSUSE 12.3 or later) this should be ok.
Comment 18 Mircea Kitsune 2015-10-23 11:09:27 UTC
On a side note: The permanent and correct solution is seemingly to update your PAM configuration. This can be done with the following commands, which I've ran and they seem to work okay for me:

pam-config -d --unix2
pam-config -a --unix