User account lost permissions after Karmic upgrade, breaking all audio

[Tristan Schmelcher]

Binary package hint: gnome-system-tools

Just today I upgraded from 9.04 to 9.10. After the upgrade, I could no longer play sound. Some debugging showed that the problem was quite simple: I was no longer in the "audio" group, so all the device files under /dev/snd/ were inaccessible to me. Hence "aplay -l" returned "no soundcards found". I opened users-admin and found that many of my Permissions had been mysteriously revoked! "Use audio devices" was only one of them. I had also lost the ability to use video devices, and several other things that I don't recall. After re-enabling those permissions, audio started working again. However, users-admin also shows that I am "Not authorized to make changes" at the bottom, even though I have the "Administer the system" permission, so I can only administer the user settings by manually sudo'ing the users-admin tool.

Note that I have another user account on this machine which did NOT lose permissions. In case it matters, the one that lost permissions is the same one that I was using when I did the upgrade.

Expected: Users should have the same permissions after Karmic upgrade, and the users-admin tool should allow me to make changes.

ProblemType: Bug
Architecture: amd64
Date: Sat Nov 7 13:21:56 2009
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: gnome-system-tools 2.28.1-0ubuntu2
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: gnome-system-tools
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors:
 (nautilus:4206): Eel-CRITICAL **: eel_preferences_get_boolean: assertion `preferences_is_initialized ()' failed
 (polkit-gnome-authentication-agent-1:4218): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

[Milan Bouchet-Valat (nalimilan)]

Thanks for this detailed report. To make it completely clear, you experienced these problems after upgrade and before running users-admin, so that it cannot be the culprit? I'm asking that because it may also have led to that situation, it's a problem we've already seen.

About the admin rights issue, being member of the admin group should be enough. What does /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf contains? Can you list the groups you are member of? You can also compare those memberships with those of the user that still works (relatively easy reading /etc/group). Are you able to perform upgrades using update-manager from the buggy user account?

About the general issue, I'm not sure what can have caused that, except update-manager itself. Once we have sorted out the problem specific to the gnome-system-tools (they may well be a mere consequence of the global bug), I think I'll move the bug to the package update-manager.

[Tristan Schmelcher (tschmelcher)]

Correct, the problem occurred before ever opening users-admin. I agree with moving the bug after the remaining rights issue is resolved.

Terminal log below. The account having the problem is "tristan". The account that didn't experience problems is "kateryna". Note though that the kateryna account does not have the administer permission nor the "configure printers" permission, so the groups are expected to be different. But I do still appear to be missing a permission that she has: "floppy". There doesn't appear to be an entry for that in users-admin (unless it has an unrelated name ...).

tristan@tinygod4:~$ cat /etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf
[Configuration]
AdminIdentities=unix-group:admin
tristan@tinygod4:~$ groups
tristan adm dialout fax cdrom tape audio dip video plugdev fuse lpadmin netdev admin sambashare
tristan@tinygod4:~$ sudo su kateryna
[sudo] password for tristan:
kateryna@tinygod4:/home/tristan$ groups
kateryna adm dialout fax cdrom floppy tape audio dip video plugdev fuse netdev sambashare
kateryna@tinygod4:/home/tristan$ exit
exit
tristan@tinygod4:~$

I can use Update Manager as myself just fine.

[Milan Bouchet-Valat (nalimilan)]

OK, so it seems there's something strange with PolicyKit. What does 'ps ax | grep polkit' reports? Please also run
pkcheck --action-id org.freedesktop.systemtoolsbackends.set --process `pidof users-admin` -u
just after having started users-amin.
What does this command reports:
pkaction --action-id org.freedesktop.systemtoolsbackends.set --verbose

Are you able to authenticate when configuring network connections? From System->Administration->Network Connections, please edit or create a connection, and check the box "Available to all users". It should then prompt you to authenticate (then you can just cancel).

[Tristan Schmelcher (tschmelcher)]

tristan@tinygod4:~$ ps ax | grep polkit
 2634 ? S 0:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
 2655 ? S 0:00 /usr/lib/policykit-1/polkitd
 6779 ? S 0:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
 6893 pts/1 S+ 0:00 grep polkit
tristan@tinygod4:~$ ps -ef | grep polkit
kateryna 2634 2448 0 Nov07 ? 00:00:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
root 2655 1 0 Nov07 ? 00:00:00 /usr/lib/policykit-1/polkitd
tristan 6779 6622 0 07:16 ? 00:00:00 /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1
tristan 6895 6873 0 07:17 pts/1 00:00:00 grep polkit
tristan@tinygod4:~$ pkcheck --action-id org.freedesktop.systemtoolsbackends.set --process `pidof users-admin` -u
Not authorized.
tristan@tinygod4:~$ pkaction --action-id org.freedesktop.systemtoolsbackends.set --verbose
org.freedesktop.systemtoolsbackends.set:
  description: Manage system configuration
  message: System policy prevents modifying the system configuration
  vendor:
  vendor_url:
  icon:
  implicit any: no
  implicit inactive: no
  implicit active: auth_admin_keep

tristan@tinygod4:~$

There is no System->Administration->Network Connections, only System->Administration->Network. It says "Not authorized to make changes" at the bottom, just like users-admin, so I can't even attempt to edit anything.

Btw, it shouldn't matter that I'm doing this all over VNC, should it?

[Milan Bouchet-Valat (nalimilan)]

Thanks! Seems that PolicyKit is running correctly. Does
sudo killall polkitd; sudo /usr/lib/policykit-1/polkitd
report any error?

It may be that you're not detected as an active user, which could come from a ConsoleKit problem. Then, connecting via VNC would actually matter, if there's a bug in that part. You can edit /usr/share/polkit-1/actions/org.freedesktop.SystemToolsBackends.policy, find the lines
    <defaults>
      <allow_inactive>no</allow_inactive>
      <allow_active>auth_admin_keep</allow_active>
    </defaults>
and put "auth_admin_keep" instead of "no" on the <allow_inactive> line. You may also set both to "yes", but don't forget to revert this change after you tested it. This should allow users to change settings without authentication, the first line is for users not detected as active (as the name says :-p ). Hope this helps...

[Tristan Schmelcher (tschmelcher)]

Starting polkit goes fine:

tristan@tinygod4:~$ sudo killall polkitd; sudo /usr/lib/policykit-1/polkitd
[sudo] password for tristan:
Registering null backend at priority -10
Using authority class PolkitBackendLocalAuthority
** (process:10436): DEBUG: Added authentication agent for session /org/freedesktop/ConsoleKit/Session10 at name :1.153, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8
** (process:10436): DEBUG: Added authentication agent for session /org/freedesktop/ConsoleKit/Session2 at name :1.46, object path /org/gnome/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8

I tried several permutations of the edits that you suggested, but none of them changed the behaviour of users-admin. Even setting both parameters to "yes" still says that I'm "Not authorized to make changes". When I start users-admin though, my polkitd daemon that I started from the terminal outputs some interesting stuff:

tristan@tinygod4:~$ users-admin
Xlib: extension "RANDR" missing on display "::1:1.0".
Xlib: extension "Generic Event Extension" missing on display "::1:1.0".
Xlib: extension "Generic Event Extension" missing on display "::1:1.0".
Xlib: extension "Generic Event Extension" missing on display "::1:1.0".

(process:10489): GLib-GObject-WARNING **: value "-1" of type `gint' is invalid or out of range for property `pid' of type `gint'
** (process:10489): DEBUG: system-bus-name::1.218 is inquiring whether unix-process:10498:16170409 is authorized for org.freedesktop.systemtoolsbackends.set
** (process:10489): DEBUG: user of caller is unix-user:tristan
** (process:10489): DEBUG: user of subject is unix-user:tristan
** (process:10489): DEBUG: checking whether unix-process:10498:16170409 is authorized for org.freedesktop.systemtoolsbackends.set
** (process:10489): DEBUG: 0x992d50
** (process:10489): DEBUG: subject is in session /org/freedesktop/ConsoleKit/Session10 (local=0 active=0)
** (process:10489): DEBUG: not authorized
** (process:10489): DEBUG:
tristan@tinygod4:~$

That seems to make it look like there are two problems: I am not detected as "active", and I am not detected as "local" either.

I think I will file a separate bug report against update-manager to cover the groups membership issue that I originally reported, since this report has clearly evolved into tracking the users-admin problem.

[Milan Bouchet-Valat (nalimilan)]

So you've found the info better than I did! I reckon you did not issue this command through VNC? In that case, that would make things trickier. As I suspected, there's something wrong with ConsoleKit, which should at least have considered you as local for my tricks to work. You may get more information by running the ConsoleKit daemon manually, just like you did for PolicyKit: it's /usr/sbin/console-kit-daemon.

I'm not sure you should open a separate report right now, because what we are debugging is not a problem in users-admin, as it's getting broader with every step we make. It may well be that the whole failure is linked in some way that I can't really explain now, as I'm not familiar with ConsoleKit. For now, I'm moving the bug to that package, and another against update-manager, hoping that somebody can help debugging the links between both problems.

[Tristan Schmelcher (tschmelcher)]

Those commands _were_ over VNC. Everything I'm doing is. I don't have any physical access to this box.

[Tristan Schmelcher (tschmelcher)]

Unfortunately running console-kit-daemon from the command-line doesn't offer anything new. It backgrounds itself and doesn't print anything when I'm launching users-admin, not even to syslog. It doesn't recognize --help either, so I don't think there are any logging options. :(

[Michael Vogt (mvo)]

update-manager does not touch the user premissions, please attach the upgrade log in /var/log/dist-upgrade so that we can check if anything else look odd. Please also check in /var/backups/group.bak if its from before the upgrade.

[Tristan Schmelcher (tschmelcher)]

Here's the dist-upgrade logs.

/var/backups/group.bak is from after the upgrade so I don't think it will help. And its contents are identical to the current /etc/group.

[Rubendebruin (rubendebruin)]

I've had the same problem when upgrading from 9.10 (clean install) to 10.04 using the upgrade tool.

Tried to fix it by doing a sudo users-admin and fixing the permissions.
This did work at first, but after a few reboots (and maybe some updates) things started to break down again. Could not shut-down the computer, could not mount external drives (ntfs/fat). However the permissions in users-admin looked ok.