Created attachment 314629 [details] build log penguin4 david # grep -A 2 NOTE /var/log/portage/sys-auth\:polkit-0.106\:20120608-023203.log NOTE: The file /usr/lib/polkit-1/polkit-agent-helper-1 must be owned by root and have mode 4755 (setuid root binary) NOTE: The file ${exec_prefix}/bin/pkexec must be owned by root and have mode 4755 (setuid root binary) NOTE: The directory /etc/polkit-1/rules.d must be owned by user 'polkitd' and have mode 700 NOTE: The directory /usr/share/polkit-1/rules.d must be owned by user 'polkitd' and have mode 700 penguin4 david # ls -l /usr/lib/polkit-1/polkit-agent-helper-1 -rws--x--x 1 root root 14688 Jun 7 22:33 /usr/lib/polkit-1/polkit-agent-helper-1 penguin4 david # ls -l /usr/bin/pkexec -rws--x--x 1 root root 23168 Jun 7 22:33 /usr/bin/pkexec Those two should be 4755 and appear to be 4700 penguin4 david # ls -al /etc/polkit-1/rules.d/ total 12 drwx------ 2 polkitd root 4096 Jun 7 22:33 . drwxr-xr-x 3 root root 4096 Jun 7 22:34 .. -rw-r--r-- 1 root root 322 Jun 7 22:33 50-default.rules penguin4 david # ls -al /usr/share/polkit-1/rules.d/ total 8 drwx------ 2 polkitd root 4096 Jun 7 22:33 . drwxr-xr-x 4 root root 4096 Jun 7 22:33 .. seems right on the latter two directories
Created attachment 314631 [details] emerge --info polkit
"Those two should be 4755 and appear to be 4700" why? Isn't this a security feature to not let all others read permissions? So: If you give a special user a permission in /etc/polkit-1/rules no other penetrator can read your file names of these specials.
(In reply to comment #0) I have different symtoms (gdm or xdm or start x) does start, but I can confirm that this new polkit breaks my system. I "fixed it with" emerge -1 =polkit-0.105 =udisks-1.97.0-r1
My kde-4.8.3 runs as usual. But I don't see a process using the new user:group polkitd:polkitd
@Ulenrich I do agree that 4700 would be more secure and there should be no need for those permissions when something like gdm is executed. But looking above those permissions are 4711 and not 4700 as originally commented. In /etc/group I had a polkitd:$id: but not polkitd:$id:polkitd Perhaps the 4755 recommendation is so the agent executing polkit will be able to read the policies? (plausible analogy --> a normal user executing a shutdown from within a WM.) Logging off fails presently. Even after 'usermod -d /var/empty polkitd' which does seemingly allow local policy to be implemented. Changing to 4755 had no affect on that though.
@Cozatt, I dont understand your group my /etc/group: polkitd:x:991: my passwd: polkitd:x:113:991:added by portage for polkit:/dev/null:/sbin/nologin after the new polkit. Which is really neat, but there should be a process running this new user polkitd (dbus? polkit? consolekit?), which is not running (kdm-4.8.3)
I used $id to show that it would not necesarily be the same. Mine was actually polkitd:992: I have not looked at the other file,
@Cozatt do you admitt this bug and other new polkit bugs are not really polkit related but perhaps dbus that must be adpted to the new polkit version?
The executables are 4711 (not 4700!) instead of 4755, but that's intentional: portage removes the read bit for group and other from setuid executables (look for "sfperms" in man make.conf) as it's unnecessary and a potential security problem. The directories have the permissions polkit suggests. Closing this as invalid. If you are sure 4711 instead of 4755 is causing problems (which is highly unlikely) please provide more information. If the new polkit is not working for you the most likely cause is bug #420269 (nonsensical homedir for the new user), which I am about to confirm.
