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.
Plasma screen locker does not let non-local users unlock screen =>
Plasma screen locker does not let non-local users unlock screen (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.
icolas LÃ©cureuil will try to reproduce with David Walser's help.
icolas LÃ©cureuil will try to reproduce with David Walser's help. =>
Nicolas LÃ©cureuil will try to reproduce with David Walser'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.
OK, if your domain is example.com, you need to have...
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
proxiable = true
workgroup = EXAMPLE
realm = EXAMPLE.COM
kerberos method = secrets and keytab
security = ads
passwd: files sss
shadow: files sss
group: files sss
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" />
# 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
Nicolas LÃ©cureuil will try to reproduce with David Walser's help. =>
Nicolas Lécureuil will try to reproduce with David Walser's help.
Might be related to bug 18986?
(In reply to Rémi Verschelde from comment #25)
> Might be related to bug 18986?
I doubt it.
(In reply to David Walser from comment #26)
> (In reply to Rémi Verschelde from comment #25)
> > Might be related to bug 18986?
> I doubt it.
In fact, no it isn't. I had removed kwallet from my PAM configuration already when I discovered this bug.
Could there be some commonality in that pam has problems handing over the password to kwalletd in the one case and to kscreenlocker in this case?
Is it just Mageia that is having the problem or is the same problem occuring in the latest (plasma5) versions of other operating systems?
I have uploaded my fixed pam_mount which might fix this. If you do get around to trying to reproduce this, please try a chmod 600 /etc/security/pam_mount.conf.xml to see if it triggers the issue again.
Nicolas Lécureuil will try to reproduce with David Walser's help. =>
possibly fixed by pam_mount-2.16-2.mga6
I think world readable pam_mount is a security issue. If you mount encrypted partitions with pam_mount, it contains a lot of inflation about cipher, location of encrypted password files etc... I would not recommend to do so...
Sorry, it's really not an option any more for it not to be world-readable. Both KDE and GNOME's screen locker's will not work if it isn't readable.
So, for a lock screen of KDE and Gnome we allow ourselves a security breach?
Please, add a big warning in the errata if there are no other solutions. Maybe there is a way to have an "include" command in pam_mount to include sensitive files?
It's not a security breach, first of all. Second of all, not being able to unlock your screen means the whole thing is basically not functional.
Having mount information world-readable should be no different than /etc/fstab or local auto-mounter maps. If you're putting sensitive information in there, that's a configuration issue on your part, not a packaging issue. There doesn't need to be a warning. If you're putting sensitive information in there, you know you're doing it and need to protect it accordingly. There shouldn't be a need for that, however. If pam_mount is mounting something with encryption, it should be using the same password for the encryption as the login password for the user, so that pam_mount can use that password without you having to hard-code it in the configuration. Linux.com did a series of articles over the past year about recommended security practices for kernel developers. They specifically mentioned that using different passwords for hard disk encryption and logging in offers no additional security.
If you think an include mechanism would help you (it sounds like a decent idea to me), and it would work with the screen lockers to do so, I encourage you to implement it. Don't count on upstream doing anything at this point from what I've seen.
I think it is a security issue and that's the way pam_mount works. The file you put world readable HAS to contain sensitive information. I don't mean the password, but information that you would have like to remain private. For this reason, pam_mount defaults this file to be not world readable.
From man pam_mount.conf:
<volume path="/home/%(USER).img" mountpoint="~" cipher="aes-cbc-essiv:sha256" fskey‐cipher="aes-256-cbc" fskeyhash="sha1" fskeypath="/home/%(USER).key" />
Any user will have access to the kind of cipher, hash and the path of your encrypted key.
Now, I still believe that if the KDE and GNOME lockscreens locks due to this, that's clearly a KDE and GNOME bug right? Not pam_mount. The way we fix it is not the way to go, and if we go this way, yes, you should add an errata.
It most certainly does not need to contain sensitive information and I don't see any in your example, nor would there be for typical cifs mounts and the like. Again, if you have something sensitive, that's particular to your configuration, not a general issue that would affect all use cases.
I certainly don't disagree that it doesn't make much sense that the screen lockers behave this way, especially as KDE in Mageia 5 didn't, but they do in Mageia 6 and RHEL as well. Right now, this is the only fix. If you feel that an entry in the release notes or something is appropriate, feel free to add it. If you want to file bugs with GNOME and KDE, that's fine as well. Note that I don't see Fedora forcing the permissions to 600 either.
can someone test this ?
As it involves setting up remote access, it's not something that's going to
normally affect running a live iso.
On an installed system, it can be fixed by an update after release, so changing
importance from a release blocker to high.
If we don't care about this bug enough to test or fix it, I'll just assume that I already did and close it. It can be re-opened if someone discovers that the bug still exists.