"Authorization failed" when trying to edit anything

Bug #1074657 reported by Marius B. Kotsbak on 2012-11-03
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
software-properties (Ubuntu)
Undecided
Unassigned

Bug Description

When I try to disable or remove something in "other software" tab in software sources dialog, I get an error:

"Authorization failed.": "Software sources can't be changed without permission.".

This problem started in Quantal, and is not bug #1058072 since I did not cancel any auth prompts.

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: software-properties-gtk 0.92.9
ProcVersionSignature: Ubuntu 3.5.0-18.29-generic 3.5.7
Uname: Linux 3.5.0-18-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Sat Nov 3 15:13:39 2012
InstallationDate: Installed on 2010-07-04 (852 days ago)
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100427.1)
MarkForUpload: True
PackageArchitecture: all
SourcePackage: software-properties
UpgradeStatus: Upgraded to quantal on 2012-09-28 (35 days ago)

Marius B. Kotsbak (mariusko) wrote :
description: updated
Edward Donovan (edward.donovan) wrote :

This doesn't help you much, but - I think this problem isn't really related to bug 1058072. The point of that bug is, that if you hit cancel, an error message is unnecessary. The code is working fine; it's a design issue.

In this case, you're not hitting cancel, but getting a genuine, unexplained failure, that does lead to the same dialog coming up.

That's how I understand it, from what's written so far, anyway. Thanks.

Marius B. Kotsbak (mariusko) wrote :

That is correct. A workaround is to run it through sudo.

James (morris-570) wrote :

Just to be clear, you need to run

sudo update-manager

It seems like ubuntu is littered with these bugs of not prompting for privilege elevation and when a novice user (like me) needs to 'run it through sudo' it's nice to know what program you need to run (since, after all, the cli executable is not 'Software Updater'). I'm sure it's possible to find out what program it is through the menu system of whatever ubuntu flavor you're using, but most people learn how to 'sudo something' long before the inner workings of their gui menuing system.

Jacob Winski (winski) wrote :

I also have this problem. Steps to reproduce:
1) Open software sources (as regular user)
2) Goto "Other Software" tab
3) Remove entry

Result:
Authorization failed.
Software sources can't be changed without permission.

When running Software Sources with massive debug I get no debug error:
software-properties-gtk -m

dbus properly registers software-properties-gtk

This is very frustrating because nothing seems to be giving out error messages. The following logs show no errors:
/var/log/syslog
/var/log/ConsoleKit/history
/var/log/messages
/var/log/dmesg
/var/log/kern.log

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in software-properties (Ubuntu):
status: New → Confirmed
Jacob Winski (winski) wrote :

This looks to be caused by improper session launch.

How to reproduce this problem:
1) open a terminal and check what your DISPLAY variable is set at and write it down:
echo $DISPLAY
NOTICE: I assume your DISPLAY variable is set to :0
If not, please use the variable that you wrote down instead
2) change to vt1 via ctrl+alt+f1
3) login
4) replace your shell via:
4a) for Unity:
DISPLAY=:0 unity --replace
-- or --
3b) for Gnome Shell:
DISPLAY=:0 gnome-shell --replace
4) go back to your shell (vt7) via ctrl+alt+f7 and wait a few seconds while your shell restarts

You should now experience the "Authorization failed" issue.

Open up Run command via alt+f2 and start your shell:
a) for Unity:
unity --replace
b) for Gnome Shell:
gnome-shell --replace

The "Authorization failed" issue should not longer exist.

At first I thought this was a polkitd issue, but alas, polkitd is always running, even when experiencing the issue:
/usr/lib/policykit-1/polkitd --no-debug

dbus-daemon is also always running.

It seems like something with the DISPLAY is not getting properly handled.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers