http://bugzilla.opensuse.org/show_bug.cgi?id=1160995 http://bugzilla.opensuse.org/show_bug.cgi?id=1160995#c1 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt@suse.com, | |GCCHelp@merckgroup.com Component|KDE Workspace (Plasma) |Basesystem Assignee|opensuse-kde-bugs@opensuse. |bnc-team-screening@forge.pr |org |ovo.novell.com Flags| |needinfo?(GCCHelp@merckgrou | |p.com) --- Comment #1 from Fabian Vogt --- (In reply to GCC Da DiscoveryTechnologies from comment #0)

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#c3 GCC Da DiscoveryTechnologies changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(GCCHelp@merckgrou | |p.com) | --- Comment #3 from GCC Da DiscoveryTechnologies --- Thanks for your reply, Fabian. 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. strace produces this output: seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) (INJECTED) seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=61, filter=0x5567248f7740}) = -1 EINVAL (Invalid argument) (INJECTED) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=3406, si_uid=1020, si_status=0, si_utime=0, si_stime=1} --- +++ exited with 0 +++ See attachment for the complete output of the command. Sorry, I don't know about the seccomp sandbox. Can I modify/configure 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 --- (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.) 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#c7 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #7 from Fabian Vogt --- (In reply to Fabian Vogt from comment #6)

(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#c11 GCC Da DiscoveryTechnologies changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED |--- --- Comment #11 from GCC Da DiscoveryTechnologies --- Sorry to report this, but... ...even with the updated version 5.12.9 installed out in the wild I found a user for who kscreenlocker is still crashing. Above seccomp strace command produces this output % strace -e trace=seccomp -e inject=seccomp:error=EINVAL -o opensuse1160995-concordia /usr/lib64/libexec/kscreenlstrace -f -o opensuse1160995-concordia.strace /usr/lib64/libexec/kscreenlocker_greet --testing seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument) (INJECTED) seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=61, filter=0x55a9530d05c0}) = -1 EINVAL (Invalid argument) (INJECTED) +++ exited with 0 +++ For most of the users, the patch worked fine. Currently I can't find a difference between the users where it works and where it does not. -- 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#c13 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(GCCHelp@merckgrou | |p.com) --- Comment #13 from Fabian Vogt --- Backtrace would be necessary for further investigation. -- 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 changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(GCCHelp@merckgrou | |p.com), | |needinfo?(fvogt@suse.com) | --- Comment #15 from GCC Da DiscoveryTechnologies --- Created attachment 828922 --> http://bugzilla.opensuse.org/attachment.cgi?id=828922&action=edit Stack trace of crashed "kscreenlocker_greet --testing" Found another user where kscreenlocker also crashes and asked him to collect attached strace. Version of kscreenlocker package was 5.12.9-lp151.5.1 on this machine. -- 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#c17 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(fvogt@suse.com) | --- Comment #17 from Fabian Vogt --- (In reply to GCC Da DiscoveryTechnologies from comment #15)

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#c19 --- Comment #19 from GCC Da DiscoveryTechnologies --- Some additional information: If only one user is logged in, there is no problem. If a second session is opened, _all_ users get the problem that screenlocker crashes on every activation. -- 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#c21 --- Comment #21 from GCC Da DiscoveryTechnologies --- Created attachment 829881 --> http://bugzilla.opensuse.org/attachment.cgi?id=829881&action=edit strace of kscreenlocker_greet crashing for followup single user inheriting the crash-problem -- 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#c23 Fabian Vogt changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk@suse.com Flags| |needinfo?(kukuk@suse.com) --- Comment #23 from Fabian Vogt --- I assume any use of NIS spawns a thread which keeps running in the background, which complicates things. It dies because of a FD leak, leading to open failing with EMFILE and eventually a crash. open("/var/yp/binding/ddi.3", O_RDONLY|O_CLOEXEC) = 37 fstat(37, {st_mode=S_IFREG|0644, st_size=144, ...}) = 0 read(37, "\0\0\0\1\0\0\0\3udp\0\0\0\0\1\0\0\0\1\0\0\0\4inet\0\0\0\3"..., 4096) = 144 open("/etc/services", O_RDONLY|O_CLOEXEC) = 38 ... close(38) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 38 ... close(38) = 0 socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = -1 EPERM (Operation not permitted) open("/etc/services", O_RDONLY|O_CLOEXEC) = 38 ... close(38) = 0 open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 38 ... close(38) = 0 open("/var/yp/binding/ddi.3", O_RDONLY|O_CLOEXEC) = 38 The fd 37 is never closed. @kukuk: Which library causes those open calls and why? kscreenlocker_greet does basically this: getpwuid(geteuid()); seccomp(...); // Block open(..., O_WRONLY), socket(...), etc. getaddrinfo(...); // If something tries to access the network, has to be blocked Is this something which libnss_nis can't deal with by design or would it be enough to fix the fd leak in whatever library causes it (libtirpc)? -- 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 --- (In reply to Thorsten Kukuk from comment #27)

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#c31 --- Comment #31 from GCC Da DiscoveryTechnologies --- Created attachment 829982 --> http://bugzilla.opensuse.org/attachment.cgi?id=829982&action=edit strace of kscreenlocker_greet crashing with NIS client configured with IP addresses of NIS servers - changed /etc/yp.conf to only include IP addresses of the servers - rebooted - had two affected users log in on graphical console - no crash on first try :-) - kscreenlocker crash on second try :-( - strace much bigger than before So it looks like kscreenlocker_greet got further before it crashed? -- 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 --- 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? 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. 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. -- You are receiving this mail because: You are on the CC list for the bug.