Admin tools require admin group membership

[Aurelien Naldi]

Binary package hint: gnome-system-tools

On my edgy system, the tools bundled within gnome-system-tools can be launched without entering a password. Even by a user that should not be allowed to run it. Once launched, it still performs well, modifying the system without ANY check.
I am not sure that nothing is wrong with my system has it has been updated from dapper (from breezy).

My /etc/sudoers looks like a default one :
    Defaults !lecture,tty_tickets,!fqdn
    root ALL=(ALL) ALL
    %admin ALL=(ALL) ALL

The binaries are not setuid, the UI run normally as a simple user.

pitti: This should be fixed in Edgy, too, since it allows malicious programs (even things like a firefox plugin) to modify system settings. edgy-proposed debdiffs attached, explanations of patches are in comment 41 and 42.

[Matt Zimmerman (mdz)]

See https://help.ubuntu.com/community/RootSudo

[Aurelien Naldi (aurelien.naldi)]

Sorry, I might have not explain well the problem.
I _know_ about sudo. When my system was dapper, launching one of the ****-admin prompted for my password and only members of the admin group could do it. Now it can be launched by anyone, even non-admin users and without prompting for any password (and my password is _not_ cached).

Other administration tools (gdmsetup, synaptic...) still behave normally: prompt for my password and can not be launched by other users.

This is not a misconception of what is sudo. This is _ANY_ user allowed to run administration tools: able to add themself to the admin group and then to get a real root shell.

I am not sure that this is not a bug in my system only, but the _is_ a bug, a pretty serious one!

[Martin Pitt (pitti)]

Indeed this is due to the new architecture of gnome-system-tools in Edgy. The backend now is entirely separate, the frontend runs as normal user, and they communicate over dbus. The current dbus policy is to allow access to members of the admin group. Thus there is no sudo involved any more.

This drops the additional safeguards that gksudo provides, like verifying the person that is currently sitting on the computer (if there is no active sudo timestamp at least), although with physical access this merely provides a delay and does not stop any local attacks.

I'm aware that it is less than ideal, but until we have PolicyKit (in edgy+1, I assume) we have to find a compromise for this. Right now privilege transition works the same way as gnome-power-manager and friends get root access.

[Aurelien Naldi (aurelien.naldi)]

indeed, when launched by a normal user, users-admin crashes and the terminal output says that this user was not allowed to send a dbus message.
Sorry for the extra fear it gave me. I am still pretty sure to have launched it as a normal user a while ago, but this was either a separate (fixed) bug or some mis-remember on my part.
I still dislike being able to launch it without sudo controlling (it is especially bad for people with custom sudo configuration, but they can work around it manually I guess). Anyway, if a member of the admin group is compromised, something bad can be done, it only makes things a bit easier.

Nice to have the UI running fully as non-priv user anyway!

[Matt Zimmerman (mdz)]

On Tue, Sep 12, 2006 at 05:42:28AM -0000, aurelien naldi wrote:
> Sorry, I might have not explain well the problem.
> I _know_ about sudo. When my system was dapper, launching one of the ****-admin prompted for my password and only members of the admin group could do it. Now it can be launched by anyone, even non-admin users and without prompting for any password (and my password is _not_ cached).

Apologies for the confusion; as you might expect, we receive a substantial
volume of "bug" reports which look very much like the one you submitted, but
are simply misunderstandings of sudo's caching mechanism.

--
 - mdz

[Gianfranco Liporace (dr.kabuto)]

Hi,
I've a similiar problem, when a system-tool is launched, no password is prompted anymore, and no info is displayed (i.e. no users in users-admin e no network interfaces in network-admin). After Martin's comment, I've found that no admin group is present so after creating it (and restarting dbus) all works well.
I question: it is a bug in my system (with dapper there weren't any problem), or something is missing during the dapper->edgy upgrade?

[Sebastien Bacher (seb128)]

How did you install you distribution? Admin is a standard group and the one used for sudo granting too

[Gianfranco Liporace (dr.kabuto)]

Hi,
I've upgraded from dapper to edgy, like i did before with warty->hoary, hoary->breezy and breezy->dapper.
Maybe something went lost between those upgrades.

[Sebastien Bacher (seb128)]

if you installed warty that's probably normal then, the admin was not used it for it and that change is not made on upgrade

[Gianfranco Liporace (dr.kabuto)]

Ah, thanks for the explanation.
Maybe mine situation isn't a common one, but this change can be applied by update-manager when edgy will be released, to make sure that the admin group is present.

[Sebastien Bacher (seb128)]

Michael, any opinion on that update-manager feature suggestion?

[magilus (magilus)]

> if you installed warty that's probably normal then, the admin was not used it for it and that change is not made on upgrade

I made a Dapper -> Edgy upgrade and the same behavior appears.

[magilus (magilus)]

I believe that this is a must fix for Edgy.. Nothing makes Ubuntu better than Windows in the security aspect when users work as Administrators and can change a lot without any security question.

[Michael Vogt (mvo)]

@Sebastian:
we could certainly add a feature to update-manager to ensure that there is a admin group. I would need a /etc/sudoers and a /etc/passwd, /etc/group from a warty install though.

[Matt Zimmerman (mdz)]

gnome-system-tools should not rely upon the existence of the admin group

[Sebastien Bacher (seb128)]

Matt, I'm not sure it can't be configured differently before starting using policykit which will not happen for edgy. Is that an issue for edgy?

[Matt Zimmerman (mdz)]

On Wed, Sep 27, 2006 at 07:42:24AM -0000, Sebastien Bacher wrote:
> Matt, I'm not sure it can't be configured differently before starting
> using policykit which will not happen for edgy. Is that an issue for
> edgy?

I'm not familiar with policykit; can you explain the issue?

--
 - mdz

[Sebastien Bacher (seb128)]

Le mercredi 27 septembre 2006 à 08:06 +0000, Matt Zimmerman a écrit :
> On Wed, Sep 27, 2006 at 07:42:24AM -0000, Sebastien Bacher wrote:
> > Matt, I'm not sure it can't be configured differently before starting
> > using policykit which will not happen for edgy. Is that an issue for
> > edgy?
>
> I'm not familiar with policykit; can you explain the issue?

The issue is not policykit. The new gnome-system-tools communicates with
the daemon over dbus, the permissions granting is done by a dbus policy.
My understanding is that dbus doesn't allow better granularity than
group membership for that at the moment, policykit is supposed to fix
that.

[Martin Pitt (pitti)]

I did not look into details yet either, but in general PolicyKit is a new system daemon that controls access to resources. You can configure policies like 'user/group foo can access dbus interface bar' and optionally add the requirement that this user has to authenticate via password. In a way it is a fine-grained version of standard unix permission checking.

As I already said I am not terribly happy with not asking for the password at all, since it opens the door for Trojans much more than our previous system did. But the only solution for that right now would be to restrict backend access to root and run all frontends with gksudo again.

[Matt Zimmerman (mdz)]

On Wed, Sep 27, 2006 at 08:33:35AM -0000, Sebastien Bacher wrote:
> Le mercredi 27 septembre 2006 à 08:06 +0000, Matt Zimmerman a écrit :
> > On Wed, Sep 27, 2006 at 07:42:24AM -0000, Sebastien Bacher wrote:
> > > Matt, I'm not sure it can't be configured differently before starting
> > > using policykit which will not happen for edgy. Is that an issue for
> > > edgy?
> >
> > I'm not familiar with policykit; can you explain the issue?
>
> The issue is not policykit. The new gnome-system-tools communicates with
> the daemon over dbus, the permissions granting is done by a dbus policy.
> My understanding is that dbus doesn't allow better granularity than
> group membership for that at the moment, policykit is supposed to fix
> that.

How about we check when launching g-s-t whether the admin group exists, and
if not, run it under gksudo?

--
 - mdz

[Matt Zimmerman (mdz)]

On Wed, Sep 27, 2006 at 08:39:19AM -0000, Martin Pitt wrote:
> As I already said I am not terribly happy with not asking for the
> password at all, since it opens the door for Trojans much more than our
> previous system did. But the only solution for that right now would be
> to restrict backend access to root and run all frontends with gksudo
> again.

That seems fine to me.

--
 - mdz

[Justin Dugger (jldugger)]

Any fix for this yet? Cuz its pretty annoying and breaks the upgrade path. Obviously the best solution would be to add myself to the admin group, if it exists, but even the Users and Groups tool is broken here. Thankfully, update-manager launches fine, but the other tools still need gksudo.

[Sebastien Bacher (seb128)]

Le dimanche 29 octobre 2006 à 17:18 +0000, Justin Dugger a écrit :
> Any fix for this yet? Cuz its pretty annoying and breaks the upgrade
> path. Obviously the best solution would be to add myself to the admin
> group, if it exists, but even the Users and Groups tool is broken here.

if there was a fix it would be mentioned on the bug or the bug would be
closed.
Why do you consider the users and groups tool as broken?

[Justin Dugger (jldugger)]

Apologies, I guess what I meant to ask was whether anyone was working to fix this. I consider it broken because figuring out how to launch the groups tool in the presence of this bug isn't easily discoverable. You can run it under "gksudo" at a command line but you still need to figure out that the tool is named "users-admin."

[Aaron C. de Bruyn (darkpixel2k)]

My bug was marked as a dupe of this bug. (Bug 69145)

I had a similar issue. No admin group. I apt-get dist-upgrade'd from dapper.

After creating the admin group and adding myself, I still get the same issue as mentioned in my bug.

Starting the services admin app gives an error:
The configuration could not be loaded
You are not allowed to access the system configuration.

[Sebastien Bacher (seb128)]

Le mardi 31 octobre 2006 à 14:42 +0000, Aaron C. de Bruyn a écrit :
> My bug was marked as a dupe of this bug. (Bug 69145)
>
> I had a similar issue. No admin group. I apt-get dist-upgrade'd from
> dapper.
>
> After creating the admin group and adding myself, I still get the same
> issue as mentioned in my bug.
>
> Starting the services admin app gives an error:
> The configuration could not be loaded
> You are not allowed to access the system configuration.

did you restart dbus since you did that?

[Aaron C. de Bruyn (darkpixel2k)]

Darn. I thought I had rebooted the box. It's working now.

So apparently this is caused by an earlier version of Ubuntu (say Dapper?) and when upgrading to Edgy the admin group isn't created?

[Sebastien Bacher (seb128)]

Le mardi 31 octobre 2006 à 16:23 +0000, Aaron C. de Bruyn a écrit :
> Darn. I thought I had rebooted the box. It's working now.
>
> So apparently this is caused by an earlier version of Ubuntu (say
> Dapper?) and when upgrading to Edgy the admin group isn't created?

that's happening for people who installed warty and are dist-upgrading
since that

[Tom Verdaat (tom-verdaat)]

Breezy -> Dapper -> Edgy

Rebooted several times. Still not solved.

Maybe this helps. The username I'm using is 'tom' which was created during the breezy installation. This user is in the following groups:

$ cat /etc/group |grep "tom"
adm:x:4:tom
dialout:x:20:tom,cupsys
cdrom:x:24:tom,hal,haldaemon
floppy:x:25:tom,hal,haldaemon
audio:x:29:tom
dip:x:30:tom
video:x:44:tom
plugdev:x:46:tom,hal,haldaemon
tom:x:1000:
lpadmin:x:104:tom
scanner:x:105:tom,cupsys,hplip

[Justin Dugger (jldugger)]

Tom,
Clearly the upgrade didn't add user "tom" to the admin group, or possibly even create one.

Workaround:
1. run "gksudo users-admin"
2. Click manage groups
3. Click add Group
4. Put "admin" as the name of the group, and put whatever users you want to allow to change system wide settings such as networking.
5. Close the users-admin program and reboot.

But thank you for clarifying that this persists from at original installs of breezy, possibly dapper installs.

[Alf-Ivar Holm (affi)]

After upgrade I was bitten by https://launchpad.net/bugs/69145 as I initially installed Breezy, in March. I have now fixed the problem by adding "admin" by hand, but what does "admin" signify that "adm" does not? My /etc/sudoers has "adm" and I was (and am) a member of "adm", but that was apparantly not enough for the new architecture.

-Affi

[Christian Niemeyer (christian-niemeyer)]

For me the error occured when I wanted to disable some services via "services-admin". Accidentally I unchecked dbus. And since there was the problem.

Fix:
Run Synaptic (should still work)
Re-Install following packages:
-gnome-system-tools
-system-tools-backend
-dbus
-libdbus-1-3
(or simply all packages in which names occur "dbus", don't know exactly, so I did)

Now try to run services-admin again and check that dbus there is enabled. Maybe Re-Login or Reboot is needed.

Hope this was helpful
Regards,
Chris

[Christian Niemeyer (christian-niemeyer)]

Sorry forgot something:

Now after Rebooting I experienced, that e.g. services-admin starts without asking permissions. Then you need to run alacarte menu editor and check the section >System >Administration and put gksu before these commands:
gksu gdmsetup
gksu users-admin
gksu time-admin
gksu services-admin
gksu network-admin

[Tom Verdaat (tom-verdaat)]

Instructions by Justin Dugger solved my problem. I guess some kind of check script should be pushed as an update of some sort, to make sure this is solved on all systems.

Not that this matters in my case, I need to completely re-install Ubuntu because of all the upgrade issues :(

[Kurt (e-mail-elmar-boos)]

Many people running ubuntu work with only one user (which is in the administrator's group) - and this is also the default.

Considering this, it is really a great security risk that the admin tools do not check the password because if the admin user gets compromised, one can easily add a new user, log in as this one and do everything.

This should be fixed as soon as possible. I know that edgy is not considered as stable as dapper, but it is considered stable. Many people are not aware that edgy does not have the same stability and that the edgy release does probably have more security holes than dapper.

Maybe it might be the time for a discussion if a third branch between the unstable and the stable one, probably something like testing in Debian, might be useful to prevent the users who want a really stable and secure system from using the releases like edgy because at this point edgy can really not be considerated stabe and secure.

[Sebastien Bacher (seb128)]

Le mercredi 29 novembre 2006 à 20:19 +0000, Kurt a écrit :

> Considering this, it is really a great security risk that the admin
> tools do not check the password because if the admin user gets
> compromised, one can easily add a new user, log in as this one and do
> everything.

The admin user already has to be compromised. And if that happen
gnome-system-tools will probably not be the only problem you will have
then

> This should be fixed as soon as possible. I know that edgy is not
> considered as stable as dapper, but it is considered stable. Many people
> are not aware that edgy does not have the same stability and that the
> edgy release does probably have more security holes than dapper.

edgy is not a LTS but it's rather stable too

> Maybe it might be the time for a discussion if a third branch between
> the unstable and the stable one, probably something like testing in
> Debian, might be useful to prevent the users who want a really stable
> and secure system from using the releases like edgy because at this
> point edgy can really not be considerated stabe and secure.

Are you making that from that only bug? Adding complexity to the system
will not prevent bugs to happen. All the versions of Ubuntu are meant to
be stable and secure and I don't think that calling edgy unsecure is a
fair statement. Using those tools require to be logged with an user from
the admin group. Right asking for the password again is better, if
somebody can connect with your admin user you already a problem though

[Matt Zimmerman (mdz)]

On Wed, Nov 29, 2006 at 10:14:46PM -0000, Sebastien Bacher wrote:
> Are you making that from that only bug? Adding complexity to the system
> will not prevent bugs to happen. All the versions of Ubuntu are meant to
> be stable and secure and I don't think that calling edgy unsecure is a
> fair statement. Using those tools require to be logged with an user from
> the admin group. Right asking for the password again is better, if
> somebody can connect with your admin user you already a problem though

Verifying the user's identity with password authentication is an important
safeguard; we explicitly do not use NOPASSWD in sudoers for this reason, and
the lack of a check in Edgy is a regression. The security team are
discussing potential ways to address this.

--
 - mdz

[Kurt (e-mail-elmar-boos)]

Sebastien Bacher wrote:

Are you making that from that only bug? Adding complexity to the system
will not prevent bugs to happen. All the versions of Ubuntu are meant to
be stable and secure and I don't think that calling edgy unsecure is a
fair statement. Using those tools require to be logged with an user from
the admin group. Right asking for the password again is better, if
somebody can connect with your admin user you already a problem though

----

The philosophy of ubuntu (as I have understood it) is that you can use, when you're a single user, the first user (which is an administrator) for your daily work because at every change of the system you must enter your password. Shurely it is much saver to use, in any case, a unprivileged user for your daily work, but very few desktop user do it because it is not very comfortable (e. g. you must change user if you want to make installations; the notification of updates only shows up if you're loged in as an administrator).

The problem of that bug are, in my opinion, other bugs which led to the execution of code with the rights of the user.

Finally I do not considerate edgy completely unsecure or unstable; I just considerate it not as stable as dapper.

[Martin Pitt (pitti)]

I have the fix ready for feisty, upload pending unfreezing the archive.

[Martin Pitt (pitti)]

Patch for gnome-system-tools.

It changes all *.desktop files to execute the frontend through gksu, and adds the 'X-KDE-SubstituteUID=true' flag, so that only administrators will see the programs in the menu (this is what it looked like in dapper).

The patch to time-tool is necessary because it connects to the user's session dbus (no other g-s-t programs do), in order to poke the screensaver to not start when changing the time. Since root does not have a session bus when running though gksu, time-admin just hangs in current edgy when run as root. The patch checks if time-admin runs as root through sudo and temporarily drops the real uid to the user so that dbus_bus_get (DBUS_BUS_SESSION, NULL) connects to the user's session bus.

[Martin Pitt (pitti)]

Patch for gnome-system-tools.

It changes all *.desktop files to execute the frontend through gksu, and adds the 'X-KDE-SubstituteUID=true' flag, so that only administrators will see the programs in the menu (this is what it looked like in dapper).

The patch to time-tool is necessary because it connects to the user's session dbus (no other g-s-t programs do), in order to poke the screensaver to not start when changing the time. Since root does not have a session bus when running though gksu, time-admin just hangs in current edgy when run as root. The patch checks if time-admin runs as root through sudo and temporarily drops the real uid to the user so that dbus_bus_get (DBUS_BUS_SESSION, NULL) connects to the user's session bus.

[Martin Pitt (pitti)]

(Sorry for the previous double comment, LP timed out)

Patch for system-tools-backends.

This changes the s-t-b admin group from 'admin' to 'root', so that /etc/dbus-1/system.d/system-tools-backends.conf does not allow access to members of the admin group any more, i. e. it changes

  <policy group="admin">

to

  <policy group="root">

[Martin Pitt (pitti)]

Hi Matt,

I propose to fix this bug in Edgy.

Bug: https://launchpad.net/bugs/59946
Impact:
 - user's password is not checked when starting a g-s-t application
 - allows malicious software (trojan horses, etc.) to silently modify
   system configuration
 - depends on 'admin' group presense and default semantics
Patch: (same for edgy and feisty)
 - run g-s-t frontends through gksu
 - only allow root to connect to s-t-b dbus interface
 - detailed explanation of the patches:
   https://launchpad.net/distros/ubuntu/edgy/+source/gnome-system-tools/+bug/59946/comments/41
   https://launchpad.net/distros/ubuntu/edgy/+source/gnome-system-tools/+bug/59946/comments/42
 - debdiffs for edgy-proposed:
   http://librarian.launchpad.net/5247800/gnome-system-tools.edgy.diff
   http://librarian.launchpad.net/5247805/system-tools-backends.edgy.diff

Thanks,

pitti
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org

In a world without walls and fences, who needs Windows and Gates?

[Martin Pitt (pitti)]

So it turned out that some more fixes are required in applets that call one of the g-s-t tools. They have to be changed to run that tool through gksudo.

First, clock-applet (from gnome-panel). The command string is fed through g_shell_parse_argv(), thus the simple string change works.

This has been tested on edgy and feisty.

[Martin Pitt (pitti)]

Next, modemlights in gnome-applets. Same approach, just here we need to prepend 'gksu --' since network-admin is called with options, and gksu must not process them.

[Martin Pitt (pitti)]

And, last but not least, gnome-netstatus. Same old story, prepending 'gksu --' to the network-admin command callout.

[Sebastien Bacher (seb128)]

I've discussed that with Martin on IRC during the week, that seems the best way to me too and the patches look good

[Martin Pitt (pitti)]

Setting to 'in progress' to comply with SRU updating practice and catching Colin's awareness.

[Martin Pitt (pitti)]

Fixed memory leak, thank to Colin for spotting.

[Colin Watson (cjwatson)]

All current patches from Martin approved for edgy-proposed.

[Martin Pitt (pitti)]

g-s-t and s-t-b are fixed in Feisty. Talked with Seb, he wants to apply the remaining minor bits (panel, applets, netstatus) with the next round of regular updates.

[Colin Watson (cjwatson)]

All fixes accepted into edgy-proposed. Please proceed to testing now.

[Martin Pitt (pitti)]

Updated s-t-b patch with an added conflicts to earlier system-tools that didn't gksu.

[Sebastien Bacher (seb128)]

fixed to feisty, I've patch gnome-nettool too, there was a similar bug open on it

[Sebastien Bacher (seb128)]

gnome-nettool was already lacking a change for that on dapper, that's not a regression and we had only one bug about about it, not sure if we want to backport the fixed to edgy

[Sebastien Bacher (seb128)]

bug #76055 has been opened about the edgy-proposed update, the shares-admin feature for nautilus requite a patch to use gksu

[Martin Pitt (pitti)]

I fixed bug 76055 in Feisty and prepared and tested the bug fix for Edgy, attaching debdiff. Apart from calling shares-admin with gksu in the nautilus plugin, this also requires to fix shares-admin itself for root operation. Its initialization function indirectly connects to the session dbus (thus it didn't appear in the initial grep) and thus needs the same 'temporarily drop to SUDO_UID' patch as time-admin got.

OK to upload to -proposed?

[Colin Watson (cjwatson)]

Sebastien: Yes, I would be inclined to fix gnome-nettool in edgy. http://librarian.launchpad.net/5484068/05_gksu_for_network_admin.patch is OK with some appropriate changelog entry.

[Colin Watson (cjwatson)]

Martin: http://librarian.launchpad.net/5593422/g-s-t.edgy-2.debdiff is OK for edgy-proposed.

[Martin Pitt (pitti)]

Colin: Thanks for review, I uploaded the new gnome-system-tools 2.15.5-0ubuntu5~prop2.

[Jani Monoses (jani)]

this affects xubuntu-system-tools as well (it's still a separate source package even if the same upstream tarball - Gauvain has a solution for this), a corresponding debdiff and SRU will follow shortly as a separate LP bug if required.

[Matt Zimmerman (mdz)]

On Tue, Jan 09, 2007 at 11:49:07AM -0000, Jani Monoses wrote:
> this affects xubuntu-system-tools as well (it's still a separate source
> package even if the same upstream tarball - Gauvain has a solution for
> this), a corresponding debdiff and SRU will follow shortly as a separate
> LP bug if required.

Please use the same bug if an update is required; open a separate task on
this one.

--
 - mdz

[Colin Watson (cjwatson)]

I've approved the second update to gnome-system-tools, uploaded by Martin (http://librarian.launchpad.net/5593422/g-s-t.edgy-2.debdiff has the diff).

[Jani Monoses (jani)]

This adds the same patch to x-s-t as g-s-t has, dropping the nautilus bits as they are not built for x-s-t. Also added the two small patches from bug 69566 that fix crashers and are already in edgy-updates for g-s-t.

[Simon Law (sfllaw)]

gnome-system-tools, system-tools-backends, gnome-panel, gnome-applets, and gnome-netstatus are approved for upload into edgy-updates. They have been regression tested to continue setting preferences while requiring password authentication.

gnome-nettool has not been tested, so it will break in Edgy. But Séb is working on a separate SRU for that.

xubuntu-system-tools has also not been tested.

[Jani Monoses (jani)]

x-s-t has not yet been approved for proposed so it cannot be easily tested.
If the new system-tools-backends goes in edgy-updates it can break un-updated x-s-t, as is the case now for those xubuntu users who have ubuntu-proposed in their sources list.

[Colin Watson (cjwatson)]

http://librarian.launchpad.net/5767658/d.diff approved for edgy-proposed, but please mention this bug number in the changelog too. Also, isn't there a debian/patches/00list file that needs to be edited to include the crash fix from Sebastien, as there was for gnome-system-tools?

After talking with Simon, this set of updates shouldn't go into edgy-updates until xubuntu-system-tools is ready, but I'm willing to waive the aging requirement as long as the Xubuntu guys have tested this thoroughly. Simon says that he'll go and talk to you about the required level of testing.

[Gauvain Pocentek (gpocentek)]

I'm testing the patches, and will upload if it's OK.

[Jani Monoses (jani)]

Colin, thanks for approving. There's no 00list file as x-s-t uses CDBS so the patch being there does it. Gauvain, feel free to upload if the diff works for you, then please ping the xubuntu-devel list thread of two weeks ago so people complaining about the breakage
update and test again. Thanks.

[Gauvain Pocentek (gpocentek)]

The patch works fine for me. I've added a reference to the bug number, added the missing line in the changelog, and uploaded to edgy-proposed.

[Martin Pitt (pitti)]

Accepted into edgy-updates. Thanks for preparing!

[Martin Pitt (pitti)]

Erm, of course I meant 'accepted into edgy-proposed'. Sorry for the typo.

[Simon Law (sfllaw)]

xubuntu-system-tools has been regression tested and it looks good. x-s-t is approved for upload to edgy-updates.

Thanks!

[Martin Pitt (pitti)]

All packages uploaded to edgy-updates and accepted.

[Martin Pitt (pitti)]

... including x-s-t.

[Floris Kruisselbrink (vloris) (vloris)]

The gnome-system-tools have stopped working for me completely now in Feisty Fawn. I'm not sure since when, when it doesn't work, my first reaction is "I can do this faster on commandline, so lets do so".

Right now, all tools show start up nice, ask for a password, but then show an empty list (empty userlist, empty sharelist, empty services list, etc.)
When started from a terminal, it gives me this warning:

floris@homeros:~$ gksu services-admin
(services-admin:17446): Liboobs-WARNING **: There was an unknown error communicating with the backends: Message did not receive a reply (timeout by message bus)

It starts up, but shows an empty services list

[Martin Pitt (pitti)]

Hi Floris,

Floris Kruisselbrink (vloris) [2007-03-08 22:46 -0000]:
> The gnome-system-tools have stopped working for me completely now in
> Feisty Fawn. I'm not sure since when, when it doesn't work, my first
> reaction is "I can do this faster on commandline, so lets do so".

Can you please open a new bug about your problem? This bug is closed
and forgotten for a long time.

[Loïc Minier (lool)]

NB: The resolution of this bug caused bug #124993 as the gconf settings are now read as root instead of as $user.

The long term fix is probably to move to PolicyKit. Alternatively, if it's not ready yet, it might be possible to switch group instead of switching user, for example "sg stb" or "gksg stb", but this isn't supported by gksu yet.