http://bugzilla.suse.com/show_bug.cgi?id=1114383 http://bugzilla.suse.com/show_bug.cgi?id=1114383#c4 --- Comment #4 from Fabian Vogt <fvogt@suse.com> --- (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 -- You are receiving this mail because: You are on the CC list for the bug.