I'm installing a new laptop with 12-CURRENT and ports from head
(compiled by me with poduriere); it turned out, that I was unable to
unlock a locked KDE session; digging into the problem I saw that the
component to validate the password (kcheckpass) was packaged into the
pkg with wrong perms:
$ tar tzvf /usr/PKGDIR.20160716/kde-workspace-4.11.21.txz | fgrep kcheckpass
-rwxr-xr-x 0 root wheel 14352 17 jul. 21:43 /usr/local/lib/kde4/libexec/kcheckpass
in older versions from head in December and Mai it was with perms '-rwsr-sr-x':
$ tar tzvf /usr/PKGDIR.20151230/kde-workspace-4.11.14_4.txz | fgrep kcheckpass
-rwsr-sr-x 0 root wheel 14352 dic. 31 2015 /usr/local/lib/kde4/libexec/kcheckpass
$ tar tzvf /usr/PKGDIR.20160501/kde-workspace-4.11.14_6.txz | fgrep kcheckpass
-rwsr-sr-x 0 root wheel 14352 may. 6 21:19 /usr/local/lib/kde4/libexec/kcheckpass
I just built kde4-workspace out of area51-trunk, and the permissions are as described; official package dated may 15 2015 has different permissions on kcheckpass in the packaged txz.
Adding a "me-too". I was able to unlock my desktop by 'chmod u+s' of kcheckpass over an SSH session thankfully.
Latest poudriere-devel has BUILD_AS_NON_ROOT=yes as default which may
be exposing the problem. The official package builds do not use this
yet. So there is a missing @mode or (mode) modifier in the pkg-plist.
Untested possible fix:
--- pkg-plist (revision 421134)
+++ pkg-plist (working copy)
@@ -229,7 +229,7 @@
(Though I found that for me simply u+s was enough without also requiring g+s)
Testing jhb's patch.
A commit references this bug:
Date: Fri Sep 2 06:59:23 UTC 2016
New revision: 421252
Correct permissions on kcheckpass
Without this, if the port is staged as non-root (default on new poudriere), the
file is installed without setuid root and fails to unlock desktops.
Submitted by: jhb
Approved by: maintainer timeout (kde, 2 months)