[Bug 1160995] New: kscreenlocker_greet dumps core for NIS accounts
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995 Bug ID: 1160995 Summary: kscreenlocker_greet dumps core for NIS accounts Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: All OS: All Status: NEW Severity: Major Priority: P5 - None Component: KDE Workspace (Plasma) Assignee: opensuse-kde-bugs@opensuse.org Reporter: GCCHelp@merckgroup.com QA Contact: qa-bugs@suse.de Found By: Customer Blocker: --- Created attachment 827582 --> http://bugzilla.opensuse.org/attachment.cgi?id=827582&action=edit Stack trace of crashed kscreenlocker_greet Screen locker does not work for NIS accounts. If I either manually lock the screen with the KDE controls or simply wait a few minutes until the screen locks itself, it crashes instead. The screen is black with a message telling that the screen locker is no longer working and how to resolve the problem from another console by unlocking it from the command line. I am reproducing the problem with the command /usr/lib64/libexec/kscreenlocker_greet --testing for easier debugging. This results in [...] Segmentation fault (core dumped) It's not related to the NVIDIA driver I am using, because it's exactly the same without, using NOUVEAU instead. Also it does not seem to be a KDE only problem, as I also can reproduce it on other desktops (Gnome, LXDE, XFCE and more). Seems to be related to NIS. It only crashes when logged in with a NIS account. Local accounts don't have this problem. systemd-coredump nicely collects the core dump (can provide this if required) and it also reports the stack trace into SYSLOG (see attachment). Happy to supply more information useful for diagnosis. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c1
Fabian Vogt
Created attachment 827582 [details] Stack trace of crashed kscreenlocker_greet
Screen locker does not work for NIS accounts.
If I either manually lock the screen with the KDE controls or simply wait a few minutes until the screen locks itself, it crashes instead. The screen is black with a message telling that the screen locker is no longer working and how to resolve the problem from another console by unlocking it from the command line.
I am reproducing the problem with the command
/usr/lib64/libexec/kscreenlocker_greet --testing
for easier debugging.
The only code in kscreenlocker_greet calling into NIS is this:
const KUser user; const QString fullName = user.property(KUser::FullName).toString(); context->setContextProperty(QStringLiteral("kscreenlocker_userName"), fullName.isEmpty() ? user.loginName() : fullName);
Maybe it's the seccomp sandbox breaking it? Can you try: strace -e trace=seccomp -e inject=seccomp:error=EINVAL /usr/lib64/libexec/kscreenlocker_greet --testing
This results in
[...] Segmentation fault (core dumped)
It's not related to the NVIDIA driver I am using, because it's exactly the same without, using NOUVEAU instead.
Also it does not seem to be a KDE only problem, as I also can reproduce it on other desktops (Gnome, LXDE, XFCE and more).
Yes, the trace looks like a bug in libtirpc/glibc. Reassigning.
Seems to be related to NIS. It only crashes when logged in with a NIS account. Local accounts don't have this problem.
systemd-coredump nicely collects the core dump (can provide this if required) and it also reports the stack trace into SYSLOG (see attachment).
Happy to supply more information useful for diagnosis.
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c2
--- Comment #2 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c3
GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c4
--- Comment #4 from Fabian Vogt
Interesting idea. Indeed, if I try your suggested command
strace -e trace=seccomp -e inject=seccomp:error=EINVAL /usr/lib64/libexec/kscreenlocker_greet --testing
the screen lock does not crash and works without problems.
I prepared a patch and build a test package. Please run: zypper ar https://download.opensuse.org/repositories/home:/Vogtinator:/boo1160995/open... boo1160995 zypper -v dup --from boo1160995 zypper rr boo1160995 And test whether the problem still occurs. The package isn't published yet, might take a few minutes for the URL to be valid.
Sorry, I don't know about the seccomp sandbox. Can I modify/configure it?
Nope, you can't even disable it... -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c5
--- Comment #5 from GCC Da DiscoveryTechnologies
I prepared a patch and build a test package.
I could access the test repo and successfully install your patch. (Did not need all RPMs as I don't have the debug and developer packages installed.) I am glad to tell that your patch fixed the problem! Even NIS users now can lock the screen with the kscreenlocker_greet command, with the KDE controls and by just waiting for the KDE timeout for locking itself. All without crash and without core dump. :-) Will this patch get assimilated into the official openSUSE update repo? May I ask what you changed in your patch? Thanks a lot for your work! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c6
Fabian Vogt
(In reply to Fabian Vogt from comment #4)
I prepared a patch and build a test package.
I could access the test repo and successfully install your patch. (Did not need all RPMs as I don't have the debug and developer packages installed.)
With "zypper -v dup --from boo1160995" it would only update the packages which you have already installed to that repo.
I am glad to tell that your patch fixed the problem! Even NIS users now can lock the screen with the kscreenlocker_greet command, with the KDE controls and by just waiting for the KDE timeout for locking itself. All without crash and without core dump. :-)
Great!
Will this patch get assimilated into the official openSUSE update repo?
Yup, once it's accepted upstream.
May I ask what you changed in your patch?
This: https://phabricator.kde.org/D26722
Thanks a lot for your work!
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c7
Fabian Vogt
(In reply to GCC Da DiscoveryTechnologies from comment #5)
Will this patch get assimilated into the official openSUSE update repo?
Yup, once it's accepted upstream.
That already happened. Change pushed to git, submission to maintenance is sr 765188. Should be released in a week or so. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c8
--- Comment #8 from GCC Da DiscoveryTechnologies
That already happened. Change pushed to git, submission to maintenance is sr 765188. Should be released in a week or so.
Thank you so much! Very appreciated! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c11
GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c12
--- Comment #12 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c13
Fabian Vogt
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c14
GCC Da DiscoveryTechnologies
Backtrace would be necessary for further investigation.
Will a strace be sufficient? Or do you need something else? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c15
GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c16
GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c17
Fabian Vogt
Created attachment 828922 [details] Stack trace of crashed "kscreenlocker_greet --testing"
Found another user where kscreenlocker also crashes and asked him to collect attached strace.
It crashes because nss is not allowed to open any sockets while running sandboxed. Does it crash after entering the password? If so, I don't see a way around disabling the sandbox completely, which I'd have to discuss with upstream. (If so, you probably leaked your password in the strace output as it logged all X11 traffic as well). If not, the fix is either not working or not deployed.
Version of kscreenlocker package was 5.12.9-lp151.5.1 on this machine.
(In reply to GCC Da DiscoveryTechnologies from comment #16)
Hello Fabian,
is there a difference between the patch rpms you provided in comment #4 (version 5.12.9-lp151.5.1) and the official update in the openSUSE update repo (version 5.12.9-lp151.2.4.1) ?
Nope.
Thanks!
-- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c18
--- Comment #18 from GCC Da DiscoveryTechnologies
(In reply to GCC Da DiscoveryTechnologies from comment #15)
Found another user where kscreenlocker also crashes and asked him to collect attached strace.
It crashes because nss is not allowed to open any sockets while running sandboxed.
Does it crash after entering the password? If so, I don't see a way around disabling the sandbox completely, which I'd have to discuss with upstream. (If so, you probably leaked your password in the strace output as it logged all X11 traffic as well). If not, the fix is either not working or not deployed.
According to the user, it "crashed by itself". So it crashed as soon as it got activated.
Version of kscreenlocker package was 5.12.9-lp151.5.1 on this machine.
(In reply to GCC Da DiscoveryTechnologies from comment #16)
Hello Fabian,
is there a difference between the patch rpms you provided in comment #4 (version 5.12.9-lp151.5.1) and the official update in the openSUSE update repo (version 5.12.9-lp151.2.4.1) ?
Nope.
Strange. I did some experiments and so far most of the crashes happened with 5.12.9-lp151.5.1 . I installed the official package 5.12.9-lp151.2.4.1 on all systems in the meantime. Will observe this closely and further I will install an additional system for experiments today. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c19
--- Comment #19 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c20
--- Comment #20 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c21
--- Comment #21 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c22
--- Comment #22 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c23
Fabian Vogt
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c26
GCC Da DiscoveryTechnologies
The configuration needs to be fixed.
The client's NIS configuration? I.e. /etc/yp.conf ? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c28
--- Comment #28 from GCC Da DiscoveryTechnologies
The client's configuration, yes, but if it is /etc/yp.conf, I don't know. I don't know your setup and thus don't know where you try to resolve something which requires NIS to resolve, but is at the same time required by NIS to make a NIS request. Make e.g. sure that /etc/yp.conf does not contain host names but IP addresses.
In fact, I do have host names instead of IP addresses of the NIS servers in the client configuration. We have been using this without problems for many years. Problems only appeared with the jump to openSUSE Leap 15.1 . Further I wonder why the problem only manifests for a few users while most of the users don't hit the problem. Nevertheless, I contacted one of the affected users and will verify it with IP addresses of the NIS servers instead. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c30
--- Comment #30 from GCC Da DiscoveryTechnologies
No idea, but if you use host names in yp.conf, make sure that /etc/nsswitch.conf is not using NIS for hosts, services, rpc. The later is a very good idea in any case.
No NIS at all or in a later order? I have # grep hosts /etc/nsswitch.conf hosts: files nis mdns4_minimal [NOTFOUND=return] dns All NIS servers are defined in /etc/hosts , so they should be resolved from there. Services is "files nis" and rpc only 'files'.
Leap 42.* was using sunrpc while Leap 15* is using ti-rpc. There are big differences in this implementations.
This can be a possible explanation for the recent appearance of the problem. (But does not explain to me why it only happens to some users.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c31
--- Comment #31 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c33
--- Comment #33 from GCC Da DiscoveryTechnologies
No NIS at all! If it cannot be solved before, then NIS is needed to solve it via NIS, which means a nice recursion.
# grep hosts /etc/nsswitch.conf hosts: files nis mdns4_minimal [NOTFOUND=return] dns
All NIS servers are defined in /etc/hosts , so they should be resolved from there.
Most likely the solver tries some variants or one variant (e.g. FQDN vs short name) is missing, and you have your recursion. This is not a good and robust idea.
I thoroughly took care to include all possible name variants in the local /etc/hosts . Nevertheless, I adhered to your advice: 1. Replaced NIS server names by their IP addresses in /etc/yp.conf 2. Removed 'nis' from the hosts line in /etc/nsswitch.conf Then I rebooted the machine. I had the affected user working on the test system the whole day yesterday. And she could not manage to crash kscreenlocker_greet again! So I believe that you are right and our configuration was involved into the crashes. I will update the configuration on all our systems with the new learnings. Thanks for your input, Thorsten! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c34
--- Comment #34 from GCC Da DiscoveryTechnologies
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995
http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c35
Fabian Vogt
To us, the problem with kscreenlocker crashing seems solved or circumvented. It did not happen again since we changed NIS and name server configuration like reported in my last comment. (And we were installing two new machines with openSUSE Leap 15.1 per week since some months.)
Nevertheless, I am still wondering:
If it was a problem with NIS configuration, why did it only affect the kscreenlocker program and nothing else?
I guess that the sandbox also prevented access to nscd, which might have an effect on this.
And if it was caused by our system configuration, why did it only affect a few users? We manage all users in NIS and all accounts are set up the same way.
Can't tell for sure. Maybe also related to caches.
If you like to further examine this or do some more troubleshooting, I would be happy to support you. I also currently do have a workstation dedicated to experiments like this.
As with fixed kscreenlocker and fixed configuration it appears to be working fine now, I'd say that there's no need for further investigation. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com