Comment # 4 on bug 1114383 from Fabian Vogt

(In reply to Matthias Gerstner from comment #3)
> (In reply to fvogt@suse.com from comment #2)
> > This is not the case anymore, now kcheckpass is just a normal binary without
> > any special capabilities.
> 
> If kcheckpass no longer needs setuid root then we should remove it from the
> permissions package, too. It's only because the location of kcheckpass
> changed that 'chkstat' doesn't reapply setuid permissions to it.
>
> > Manually adding suid/sgid permissions to a system binary is not something
> > accounted for in the package and it shouldn't need to be. Otherwise every
> > package shipping a binary would need to call %set_permissions.
> 
> Every package shipping a *setuid* binary actually needs to call
> %set_permissions as is also documented in [1].
> 
> [1]:
> https://en.opensuse.org/openSUSE:Packaging_Conventions_RPM_Macros#.
> 25set_permissions

Exactly, but kscreenlocker does not ship anything like that.
What the reporter does is like this:

$ stat /bin/cat
(not setuid)
$ sudo chmod u+s /bin/cat
$ stat /bin/cat
(setuid)
$ sudo zypper in --force coreutils
$ stat /bin/cat
(not setuid)

Which is IMO working as expected.

> The question remains why the user can no longer unlock after the `zypper dup`
> as explained in comment 0 then.

kcheckpass invoked pam_* modules as normal user, which pam_yubico does
apparently not support.
Not sure what the best fix here is:
a) Make kcheckpass setuid root again
b) Get pam_yubico to work without root privileges