polkit fails to start for me with: polkitd[3021]: Error switcing to user polkitd: Error changing to home directory /dev/null: Not a directory Perhaps the polkitd user should have /var/lib/polkit-1 as home? with proper permissions of course.
I too have a problem with the latest polkit where gdm seem to come all the way up to the login screen (it does if i downgrade polkit). I'm not sure if this is the same issue and haven't had time to look into it yet, but I just thought I'd add it as a comment for now in case others are experiencing similar issues.
Indeed, gdm only coming to a black screen (was this what you meant?) was the most obvious way this represented itself. Due to polkit not running.
A user on the forums reported that 'usermod -d /var/empty polkitd' would fix the login problem. After doing that gdm will start and the logs indicate the local policy is being executed. Logging off however still fails with polkit no longer having authority being reported in the logs as the problem.
*** Bug 420359 has been marked as a duplicate of this bug. ***
Confirming, this rendered my system somewhat useless until I made up a homedir for the polkit user. Not sure yet what the best value for that homedir actually is, I'm about to do some digging.
The daemon tries to cd to the homedir of the new user for some reason. I do not know if the current directory is later used for anything. I fixed this locally by using "/" as homedir for the user, and that's also what fedora uses (see http://pkgs.fedoraproject.org/gitweb/?p=polkit.git;a=blob;f=polkit.spec;h=fcf6f18037ad17099f7ae5f0e0d0901597eb0a2b;hb=HEAD#l79 ). As that packaging gets commits from polkit's upstream author it's probably correct :)
/ as home for polkitd works fine for me. I have no particular reason for my initial suggestions of /var/lib/polkit-1 other than the directory already existing and looking as a likely alternative. :)
I had the problem that with polkit-0.106, NetworkManager denied all actions (no new WLANs, no switching connections on an interface) so I hat to set up my network manually to be able to downgrade polkit .... :/
There is no reason for amd64 arches to be CCed in here, nothing we can do. Pulling out, please do not CC arches on your own.
*** Bug 420419 has been marked as a duplicate of this bug. ***
*** Bug 420391 has been marked as a duplicate of this bug. ***
Well, since /var/lib/polkit-1 is already created by the ebuild I'd suggest to use that one.
Everything so far reported issues are fixed in =sys-auth/polkit-0.106-r1 which is now unmasked, please give it a try
(In reply to comment #13) > Everything so far reported issues are fixed in =sys-auth/polkit-0.106-r1 > which is now unmasked, please give it a try The ewarn to change the home directory should also say to chown polkitd /var/lib/polkit-1 This permitted my user to log in, but not to log out. I then did a reboot and now all appears well.
(In reply to comment #14) > (In reply to comment #13) > > Everything so far reported issues are fixed in =sys-auth/polkit-0.106-r1 > > which is now unmasked, please give it a try > > The ewarn to change the home directory should also say to > chown polkitd /var/lib/polkit-1 > > This permitted my user to log in, but not to log out. > I then did a reboot and now all appears well. Arg, so both fperms and diropts are useless for existing directories. Bah. Fixed in -r2
FYI mounting disks in xfce-places-plugin now wants the adm password or daemon passwd neither of which exist .. instead of root passwd which does .. all due to polkit-0.106-r2 .. one improvement - I now see a password prompt again .. I imagine others will see similar issues .. any thoughts on the cure?
to be more complete .. I did reboot.. permissions on directories changed etc .. also same behaviour in thunar .. same call mechanism I suspect .. annoying .. regular permission mounts such as a usbstick are okay .. this only effects volumes needing root permissions to mount or so it seems ..
(In reply to comment #17) > to be more complete .. I did reboot.. permissions on directories changed etc > .. also same behaviour in thunar .. same call mechanism I suspect .. > annoying .. > regular permission mounts such as a usbstick are okay .. this only effects > volumes needing root permissions to mount or so it seems .. Is polkit-gnome installed? It should let you choose the user, every time or always.
well .. I have been using lxpolkit instead .. I'll check to see if there is a difference .. and let you know ..
no difference between polkit-gnopme and lxpolkit as to what is offered for choices .. adm and daemon only .. cannot even enter another user manually .. with either .. Just slight appearance and behaviour differences .. :(
so far a work arround is to add myuser to the adm group which then shows up in the list .. is this good practise?
(In reply to comment #21) > so far a work arround is to add myuser to the adm group which then shows up > in the list .. is this good practise? yes, that is how it's designed to be used
so instead of using wheel we now use adm .. just for polkitd .. what has this change gained us? .. wasn't the initial concern an elevation of privileges to root from wheel .. don't we still have the same issue? or am I missing something? pkexec /bin/bash ... still works
(In reply to comment #23) > so instead of using wheel we now use adm .. just for polkitd .. what has > this change gained us? .. wasn't the initial concern an elevation of > privileges to root from wheel .. don't we still have the same issue? or am I > missing something? pkexec /bin/bash ... still works the semantics of group wheel has been to restrict access to command `su` which then requires root password for gaining root. it's a group that's in existing use in most gentoo systems. group 'adm' picked since it's somewhat unused and means admin/administrator instead of creating another group like 'polkit'. but if using 'adm' is a problem for some reason, we will go for 'polkit' but I doubt it...
I have added myuser to the adm group, but when I use gnome-control-center (I use gnome-3.2), for example to add a printer, it asks for the adm password, that I do not know. Have I made something wrong?
This bug persisted for me in an update to =sys-auth/polkit-0.106-r2. Changing polkitd's home directory to something which is not /dev/null put things back in working order. (in my case /var/empty)
Can I have some clarity please? The ewarn says: WARN: postinst If home directory of unix-user "polkitd" is set to /dev/null, run: # usermod -d /var/lib/polkit-1 polkitd But there are conflicting statements; One user says " usermod -d /var/empty polkitd " another user suggests " usermod -d /var/lib/polkit-1 polkitd " Which is which? What am I supposed to do?
(In reply to comment #27) > Can I have some clarity please? > The ewarn says: > WARN: postinst > If home directory of unix-user "polkitd" is set to /dev/null, run: > # usermod -d /var/lib/polkit-1 polkitd > > But there are conflicting statements; > One user says > " usermod -d /var/empty polkitd " > > another user suggests > > " usermod -d /var/lib/polkit-1 polkitd " > > Which is which? > What am I supposed to do? Follow what the ebuild says which is usermod -d /var/lib/polkit-1 polkitd
Many thanks Doug.
I did usermod -d /var/lib/polkit-1 polkitd and added myuser to the adm group, but, even with today upgrade to version 0.106-r3, if I did pkexec /bin/sh it asks for the adm password. Whatever I tape, I obtain Error executing command as another user: Not authorized This incident has been reported. What could I do?
Doug, Samuli, others on this thread, thanks for the responses and for the work around. However, now I'm running into privilege and security issues with KDE because of my user now being in the 'admin' group. Having my normal user residing in this group is causing me a ton of headaches and unwanted side-effects. For example, prior to this change, whenever I evoked a system settings change that required 'superuser' privileges such as, editing the kdm greeter, kdesu would launch asking for my root password. Now any such modifications launch a policykit applet which only wants my user password for access. Furthermore the default settings for this applet is to remember the password permanently across sessions! This is very bad practice and unsafe IMHO. Now I'm just a truck driver, not a programmer, but I can see all kinds of security issues or at least mischief occurring, when all one needs to do is know a single regular user's password to gain access to the innermost workings of the system.
Another example I just ran into: in Dolphin, mounting my Windows partition now requires my user password (entered as either admin or my user name) instead of asking for my root password to gain access. The more I explore around the more things I'm seeing as being potentially vulnerable. Call me neurotic or paranoid, but I don't feel comfortable with this. The must be a safer, more secure solution than the status quo.
(In reply to comment #15) > Fixed in -r2 I use gnome-3. When I try to change the timezone from the date and time settings dialog, I need to give the adm password. OK. But the adm password is not accepted. This appears to be caused by adm not being a "real user", i.e., can't log in. So I gave it a home directdory /var/lib/adm to agree with /var/lib/polkit-1, and set its shell to /bin/bash. Now it works. 1. Is this too risky? 2. If so, what should be done instead? 3. Should the ebuild be doing this?
cpufreq-set does no more work: root@leopard:/root(15)# cpufreq-set -c0 -g permformance Error setting new values. Common errors: - Do you have proper administration rights? (super-user?) - Is the governor you requested available and modprobed? - Trying to set an invalid policy? - Trying to set a specific frequency, but userspace governor is not available, for example because of hardware which cannot be set to a specific frequency or because the userspace governor isn't loaded? root@leopard:/root(16)# gzip -cd /proc/config.gz | grep -i cpufreq # CONFIG_X86_PCC_CPUFREQ is not set CONFIG_X86_ACPI_CPUFREQ=m root@leopard:/root(17)# lsmod | grep -i acpi acpi_cpufreq 4885 1 mperf 1051 1 acpi_cpufreq root@leopard:/root(18)# gzip -cd /proc/config.gz | grep -i gov # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y root@leopard:/root(19)# qlist -Iv polkit gnome-extra/polkit-gnome-0.105 kde-misc/polkit-kde-kcmodules-0.98_pre20101127 sys-auth/polkit-0.106-r5 sys-auth/polkit-kde-agent-0.99.0 sys-auth/polkit-qt-0.103.0
(In reply to comment #34) > cpufreq-set does no more work: This bug is for polkitd user needing home directory which has been fixed ages ago. This bug is NOT for collecting random issues which might or might not be related to the polkit upgrade. New issues get new bugs as usual.
For users in Comment #31, Comment #32, and Comment #33: Upgrade to polkit-0.106-r5. It has the old behavior. Forget about the 'adm' experiment which went wrong because of some agents not handling it properly (some were asking for wrong password, user 'adm' was not intended to be used at all, only group 'adm')
