Bug 19103 - Plasma screen locker does not let non-local users unlock screen (PAM issue?)
Summary: Plasma screen locker does not let non-local users unlock screen (PAM issue?)
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
: release_blocker critical
Target Milestone: ---
Assignee: KDE maintainers
QA Contact:
Keywords: UPSTREAM
Depends on:
Blocks: 17523
  Show dependency treegraph
Reported: 2016-07-29 18:33 CEST by David Walser
Modified: 2017-04-17 20:40 CEST (History)
5 users (show)

See Also:
Source RPM: plasma-workspace-5.7.2-3.mga6.src.rpm
Status comment: Nicolas Lécureuil will try to reproduce with David Walser's help.

ltrace -f /usr/libexec/kcheckpass on Cauldron (1.54 KB, text/plain)
2016-08-12 18:33 CEST, David Walser
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5 (2.64 KB, text/plain)
2016-08-12 18:35 CEST, David Walser

Description David Walser 2016-07-29 18:33:06 CEST
In Plasma's default configuration, it automatically locks the screen after some inactivity.  For a local user, I was able to unlock the screen.  For a user in Active Directory, which I'm able to use via sssd, unlocking the screen fails.
Comment 1 Nicolas Lécureuil 2016-08-05 23:41:25 CEST
Please report this bug upstream
Comment 2 David Walser 2016-08-09 21:38:16 CEST
Appears to be:
Comment 3 David Walser 2016-08-10 14:40:12 CEST
It doesn't sound like upstream is going to be of any help here.  Our PAM configurations haven't changed, but they say their code hasn't changed.
Comment 4 David Walser 2016-08-12 18:31:36 CEST
I suppose upstream could be right, this might be a PAM issue and not with kcheckpass itself.  Running kcheckpass with ltrace -f, I notice a start difference between Mageia 5 and Cauldron.  I'll attach logs.
Comment 5 David Walser 2016-08-12 18:33:39 CEST
Created attachment 8337 [details]
ltrace -f /usr/libexec/kcheckpass on Cauldron

I edited the log to show my password as "password"
Comment 6 David Walser 2016-08-12 18:35:54 CEST
Created attachment 8338 [details]
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5
Comment 7 Philippe Makowski 2016-08-13 15:28:27 CEST
(In reply to David Walser from comment #4)
> I suppose upstream could be right, this might be a PAM issue and not with
> kcheckpass itself.  Running kcheckpass with ltrace -f, I notice a start
> difference between Mageia 5 and Cauldron.  I'll attach logs.

you should see the problem with journalctl SYSLOG_FACILITY=10
in fact we need pam 1.3.0-5 in core/release
Comment 8 Anne Nicolas 2016-08-27 16:06:00 CEST
Any new information David on that one ?
Comment 9 David Walser 2016-08-27 16:14:09 CEST
No.  I believe this is a PAM issue.
Comment 10 Bruno Cornec 2016-10-17 11:37:15 CEST
Is it still happening now that pam-1.3.0-5 is in mga6 ?
Comment 11 David Walser 2016-10-17 12:28:44 CEST
PAM 1.3.0 was already in Cauldron when this was happening.  We just didn't immediately realize that since Sophie was using an outdated mirror.
Comment 12 Nicolas Lécureuil 2016-11-06 15:43:20 CET
any news on this ?
Comment 13 David Walser 2016-11-06 15:45:05 CET
Someone needs to set up a test environment for this.  I don't have access to the resources anymore, but this is an important bug.
Comment 14 Samuel Verschelde 2016-12-03 21:59:36 CET
It has been said in today's meeting that Nicolas will try to reproduce with David's help.
Comment 15 Nicolas Lécureuil 2017-01-03 17:29:51 CET
a coworker did the test and it worked, not with mga tools to configure the authentification but by configuration by hand.
Comment 16 Rémi Verschelde 2017-03-06 10:37:24 CET
How should we debug this further and hopefully find a fix? Should it stay as blocker for Mageia 6, or will it have to do with an errata entry and high priority for Mageia 7?
Comment 17 David Walser 2017-03-06 12:09:14 CET
Since it will make Plasma completely unusable in affected environments, it really needs to be fixed, but one challenge is that I found this bug two jobs ago and am no longer in an environment where I can easily set up a reproducer for this.  The first step is for someone to do so, so it can at least be tested and maybe debugged.  If it can't be reproduced, then I guess we'll just have to hope for the best...
Comment 18 Samuel Verschelde 2017-03-06 16:07:14 CET
QA testers, could any of you try to reproduce this bug which is currently set as release_blocker, so that we can decide about it?
Comment 19 Nicolas Lécureuil 2017-03-06 16:29:55 CET
i would need a procedure to reproduce, i have some windows here, i can install some windows server, etc if needed but i don't know how to reproduce
Comment 20 Nicolas Lécureuil 2017-03-22 15:40:21 CET
i still need infos to reproduce
Comment 21 David Walser 2017-03-22 23:05:03 CET
I know, I'm hoping to get to my Mageia bugs this weekend.
Comment 22 Nicolas Lécureuil 2017-03-27 16:03:41 CEST
some news ?
Comment 23 David Walser 2017-03-28 03:01:50 CEST
Actually, maybe I do have some news.  Having built a pam_mount package for RHEL at work based on the Mageia package, I have run into similar problems, and have figured out that it is due to pam_mount.conf.xml not being world readable.  Strangely, this did not cause a problem with KDE 4 on Mageia 5, but it does on RHEL 7.  As I was using pam_mount at my old job, it may have been the real cause.  Other than that, the configuration at the old job was sssd authenticating against Active Directory.  I will try to give more details on both aspects of that configuration soon.
Comment 24 David Walser 2017-03-29 15:39:23 CEST
OK, if your domain is example.com, you need to have...

in /etc/resolv.conf:
search example.com

in /etc/krb5.conf:
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 forwardable = true
 proxiable = true

in /etc/samba/smb.conf:
   workgroup = EXAMPLE
   realm = EXAMPLE.COM
   kerberos method = secrets and keytab
   security = ads

in /etc/nsswitch.conf:
passwd: files sss
shadow: files sss
group:  files sss

in /etc/sssd/sssd.conf:
domains = example.com
fallback_homedir = /home/%u
default_shell = /bin/bash
description = AD domain
enumerate = false
cache_credentials = true
case_sensitive = false
min_id = 1000
id_provider = ad
ldap_schema = ad
dyndns_update = false

With a CIFS file server called "backup" and a share called "stuff", in /etc/security/pam_mount.conf.xml:
<volume sgrp="domain users" fstype="cifs" options="sec=krb5,cruid=%(USERUID)"
        server="backup" path="stuff" mountpoint="~/stuff" />

in /etc/pam.d/system-auth:
# following line above pam_tcb.so auth line
auth required pam_mount.so disable_interactive
# following line below pam_tcb.so auth line
auth sufficient pam_sss.so use_first_pass
# following line below pam_tcb.so account line
account [default=bad success=ok user_unknown=ignore] pam_sss.so
# *NOTE* change account pam_deny.so line to pam_permit.so instead
# following line below pam_tcb.so password line
password sufficient pam_sss.so use_authtok
# following line above all session lines
session required pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent
# following lines below all session lines
session optional pam_sss.so
session optional pam_mount.so disable_interactive

If you have a domain administrator account (or one with permissions to join machines to the domain) called admin, do:
# kinit admin
# net ads join -k

Note You need to log in before you can comment on or make changes to this bug.