Mageia Bugzilla – Bug 19103
Plasma screen locker does not let non-local users unlock screen (PAM issue?)
Last modified: 2017-03-28 03:01:50 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.
Please report this bug upstream
Appears to be:
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.
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.
Created attachment 8337 [details]
ltrace -f /usr/libexec/kcheckpass on Cauldron
I edited the log to show my password as "password"
Created attachment 8338 [details]
ltrace -f -o kcheckpass.out /usr/lib64/kde4/libexec/kcheckpass on Mageia 5
(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
Any new information David on that one ?
No. I believe this is a PAM issue.
Is it still happening now that pam-1.3.0-5 is in mga6 ?
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.
any news on this ?
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.
It has been said in today's meeting that Nicolas will try to reproduce with David's help.
a coworker did the test and it worked, not with mga tools to configure the authentification but by configuration by hand.
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?
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...
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?
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
i still need infos to reproduce
I know, I'm hoping to get to my Mageia bugs this weekend.
some news ?
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.