Description of problem: I cannot start drakconf as a normal user from a KDE session under VNC, neither from the menu, nor from the command line. It works correctly from a normal KDE session, where a authorization pop-up window opens asking for the root password. I have not tested this under a Gnome VNC session, but I would expect the same issue there. I have a feeling that this is related to polkit but I have not figured out how to solve it. This issue is present also in Mageia 4. Version-Release number of selected component (if applicable): Mageia 5 alpha 1 How reproducible: Every time Steps to Reproduce: 1. Start a new VNC session from the command line or as a service. 2. Connect to the VNC session. 3. Click on the Mageia Control Center icon -> nothing happens. 4. Open a Konsole window. Write drakconf. The response is: Error executing command as another user: Not authorized This incident has been reported. Reproducible: Steps to Reproduce:
Assignee: bugsquad => mageiaWhiteboard: (none) => MGA4TOO
This issue can be fixed in the file /usr/share/polkit-1/actions/org.mageia.drakconf.policy. Change the row <allow_any>no</allow_any> to <allow_any>auth_admin_keep</allow_any> This should be the default setting in Mageia 5.
CC: (none) => waclaw66
CC: (none) => doktor5000Summary: drakconf under VNC => polkit authorisation in remote session (vnc, x2go)
X2go Mate session failed to open Mageia Control Center. Changing org.mageia.drakconf.policy as suggested above fixed the problem. Hope this will be changed in Mga 5.
CC: (none) => pernel
Thierry, what do you think about comment 1 - didn't we use this before?
CC: (none) => thierry.vignaud
comment 1 doesn't work for me, at least not in a way one might expect. I am connecting to a machine running MGA4 and x2go. When I make the recommended change to /usr/share/polkit-1/actions/org.mageia.drakconf.policy I now DO get a popup authorisation request, but it does not accept my root password. By accident I once used my user password and discovered that DOES work. Have I made the correct change?
CC: (none) => richard.j.walker
Did you try both remote & local passwords? @Colin: WDYT?
CC: (none) => mageia
Just tried using remote and local root passwords - neither works. The user password is the same on both sides of the link but the remote session authorisation is by private/public ssh key - no password. I got this in the log when I tried with the target system's root password (the only one which should work) May 17 19:10:40 Gardenshed polkit-agent-helper-1[14473]: pam_tcb(polkit-1:auth): Authentication failed for richard from (uid=501) May 17 19:10:58 Gardenshed polkit-agent-helper-1[14478]: pam_tcb(polkit-1:auth): Authentication failed for richard from (uid=501)
There is a lot more information from pkexec about what it was trying to do and for whom. Hope it helps - I don't understand a single word of it. May 17 19:10:11 Gardenshed polkitd[1162]: Operator of unix-session:c5 FAILED to authenticate to gain authorization for action org.mageia.drakconf.pkexec.run for unix-process:14419:17452966 [/usr/bin/perl /usr/bin/drakconf] (owned by unix-user:richard) May 17 19:10:11 Gardenshed pkexec[14422]: richard: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/richard] [COMMAND=/usr/libexec/drakconf] May 17 19:11:12 Gardenshed polkitd[1162]: Operator of unix-session:c5 FAILED to authenticate to gain authorization for action org.mageia.drakconf.pkexec.run for unix-process:14468:17459726 [/usr/bin/perl /usr/bin/drakconf] (owned by unix-user:richard) May 17 19:11:12 Gardenshed pkexec[14471]: richard: Error executing command as another user: Not authorized [USER=root] [TTY=unknown] [CWD=/home/richard] [COMMAND=/usr/libexec/drakconf]
And now that I have the connection information I can report that applying the same "auth_admin_keep" stanza as per comment 1 the behaviour in my remote MGA5 x2go desktop session is correct as this extract from pkexec's logging info would probably confirm: May 17 23:30:51 localhost polkitd[2195]: Operator of unix-session:c3 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.mageia.drakconf.pkexec.run for unix-process:12976:1118750 [/usr/bin/perl /usr/bin/drakconf] (owned by unix-user:stephen) May 17 23:30:51 localhost pkexec[12979]: pam_tcb(polkit-1:session): Session opened for root by (uid=502) May 17 23:30:51 localhost pkexec[12979]: stephen: Executing command [USER=root] [TTY=unknown] [CWD=/home/stephen] [COMMAND=/usr/libexec/drakconf] This remote MGA5 machine was freshly built last Thursday (14th May) and I have been keeping it up to date.
We do realise, don't we, that this failure to do the right thing on the remote desktop affects more than just MCC? If the "auth_admin_keep" change for allow_any works on MGA5 targets, should I do a block search and destroy on all of those pesky, impenetrable policy files. It would save having to track down each one as I encounter it... now I have to go and find what I need to change to get gsmartcontrol to respond to menu picks (gparted too probably).
(In reply to Leif Klingström from comment #1) > This issue can be fixed in the file > /usr/share/polkit-1/actions/org.mageia.drakconf.policy. > Change the row > <allow_any>no</allow_any> > to > <allow_any>auth_admin_keep</allow_any> > > This should be the default setting in Mageia 5. I would suggest that this is incorrect. It means someone with an inactive session can login an use our tools. One has to ask why is the session inactive in the first place? Why is it not properly registered as a session with logind? Can you give the output of "loginctl; loginctl show-session X; loginctl session-status X" where X is the session id in question (shown as part of the first comment - it's "c5" in your logs above but may have changed). This should be the session as registered on the remote machine where the actual graphical session is running. I would have thought that such sessions should be registered as active but tagged with a seat that makes it not have access to local devices (e.g. it cannot access local graphics or sound h/w etc. If this is not the case then we might need to look at x2go setups.
CC: (none) => anaselli
FWIW the same problem as described in comment#0 can be achieved by using ssh (below under maga4) [anaselli@witch ~]$ ssh -X localhost Password: [anaselli@witch ~]$ drakuser Error executing command as another user: Not authorized This incident has been reported.
mag 18 10:31:44 witch systemd[1]: Started Session c3 of user anaselli. mag 18 10:31:44 witch sshd[1101]: pam_tcb(sshd:session): Session opened for anaselli by (uid=0) mag 18 10:31:46 witch pkexec[1204]: anaselli: Error executing command as another user: Not authorized [USER=root] [TTY=/dev/pts/11] [CWD=/home/anaselli] [COMMAND=/usr/libexec/drakuser] mag 18 10:34:48 witch sshd[1112]: Received disconnect from 127.0.0.1: 11: disconnected by user mag 18 10:34:48 witch sshd[1101]: pam_tcb(sshd:session): Session closed for anaselli mag 18 10:34:48 witch systemd-logind[4483]: Removed session c3.
(In reply to Angelo Naselli from comment #11) > FWIW the same problem as described in comment#0 can be achieved by using > ssh (below under maga4) > > [anaselli@witch ~]$ ssh -X localhost > Password: > [anaselli@witch ~]$ drakuser > Error executing command as another user: Not authorized > > This incident has been reported. This sounds like something different to be honest. I also cannot reproduce: [colin@jimmy ~] ssh -X localhost Warning: Permanently added 'localhost' (RSA) to the list of known hosts. Last login: Fri May 8 14:32:37 2015 [colin@jimmy ~]$ loginctl SESSION UID USER SEAT c2 603 colin seat0 c5 492 gdm seat0 c7 492 gdm seat0 c15 603 colin 4 sessions listed. [colin@jimmy ~]$ loginctl show-session c15 Id=c15 Name=colin Timestamp=Mon 2015-05-18 09:48:29 BST TimestampMonotonic=799450675390 VTNr=0 Remote=yes RemoteHost=jimmy Service=sshd Scope=session-c15.scope Leader=29238 Audit=0 Type=tty Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 [colin@jimmy ~]$ echo $DISPLAY localhost:10.0 [colin@jimmy ~]$ drakuser ==== AUTHENTICATING FOR org.freedesktop.policykit.exec === Authentication is needed to run `/usr/libexec/drakuser' as the super user Authenticating as: Colin Guthrie (colin) Password: ==== AUTHENTICATION COMPLETE === Ignore the following Glib::Object::Introspection & Gtk3 warnings Cannot be run in console mode. In my cache the polkit auth works fine, it's just the fact that it doesn't like the X11 stuff that fails. I think this is not the fault of polkit.
@Colin what do you mean by "it doesn't like the X11 stuff that fails", i can run X applications so why shouldn't polkit ask password dialog run as well?
(In reply to Angelo Naselli from comment #14) > @Colin what do you mean by "it doesn't like the X11 stuff that fails", i can > run X applications so why shouldn't polkit ask password dialog run as well? Seems off-topic for this bug. We can discuss it elsewhere.
Possible duplicate: bug 12572
*** Bug 12572 has been marked as a duplicate of this bug. ***
CC: (none) => ftg
Whiteboard: MGA4TOO => MGA4TOO MGA5TOO FOR_ERRATASeverity: normal => major
I am getting exactly the same bug as Angelo; on 3 different machines running up to date mageia 5. I am on fvwm2, whatever terminal I use: ssh -X localhost (or other remote machines) drakconf Error executing command as another user: Not authorized This incident has been reported. cheers.
CC: (none) => dirteat
Yes, this bug remains in mga 5 fresh install with x2go. The patch according to comment 1 fixes it.
I beg to differ - a little. I have had this patch applied on my MGA4 remote system since I read comment 1 and whilst clicking the MCC icon does now produce a password entry popup, it will not accept the root password, or any other I can reasonably think of. Perhaps there is something wrong in my MGA5 local client? Richard
Just to clarify comment 20 and comment 9, this is with LXDE at both ends and it does also affect starting gparted (for instance) from the Tools menu.
I have just spotted a very similar issue, which is even not using a remote connection. Try to start gparted in a terminal as a normal user, you end up with: gparted ==== AUTHENTICATING FOR net.sourceforge.gparted.pkexec.run === GParted Partition Editor Authenticating as: root Password: polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie ==== AUTHENTICATION FAILED === Error executing command as another user: Not authorized This incident has been reported.
(In reply to Chris Denice from comment #22) > I have just spotted a very similar issue, which is even not using a remote > connection. > polkit-agent-helper-1: error response to PolicyKit daemon: > GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie Best report that as a separate bug if it's not about a remote session. polkit issues can be quite diverse, unfortunately :/
Keywords: (none) => FOR_ERRATA5Whiteboard: MGA4TOO MGA5TOO FOR_ERRATA => MGA4TOO MGA5TOO
I found that this bug is still valid in Mageia 6 and that the proposal in comment 1 solved it. Tested on two fresh installations of Mageia 6 64 bit with Mate desktop.
Still valid in Mageia 7 with X2GO session with Mate desktop. Proposal in comment 1 solved it.