users-admin (System->Administration->Users and Groups) overwrites group file

this is the file that users-admin replaced /etc/group with

Hi there
Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with the development release - Hardy Heron?. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed release. You can find out more about the development release at [WWW] http://www.ubuntu.com/testing/

Thanks in advance.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

Dear all,

I'm using the current updated Version of Ubuntu
I deleted an user wit admin-users. The an error message
appeared like "root group can not be deleteed..."
all Groups had been deleted from /etc/groups except the
the group of current login user, the deleted user and root.

Unfortunately I have no further details. But as I have seen
in the bug report list, this is a known, but not confirmed issue.

Maybe this helps.

Thank you all for you hard free work..

This is still an issue in Ubuntu 8.04
I don't know what kind of information you miss, what has to be done is clear - ban re-creation of group 'admin' (this typically happens when you create a user 'admin') and the problem is fixed. Otherwise all users except root loose their admin rights, that is highly troublesome...
What else do you want to know?

This is so easily reproducible that there can't be any doubt about this bug...

This is so easily reproducible that there can't be any doubt regarding this bug...

Ubuntu 8.10 (Ubuntu Studio) -- Users and Groups just wiped my group file. I managed to find an old backup of the file but now everything else is broken: Wireless, sound; nothing has the right permissions to run. I go from a fully working system to a complete wreck just by adding one user. It took me months to work out how to get everything working properly.

http://ubuntuforums.org/showthread.php?t=1095007

Bubla (and others): the problem with this kind of serious bugs is that we don't know how to reproduce them, and so cannot fix them. If you find it so easy to reproduce it, please tell us how. Else we'll have to close the report, knowing that the bug will bite somebody one day.

Well, just create a new user named 'admin'. That's how you reproduce the bug.
Be sure to have some sort of a rescue CD nerarby, though.
This should be it, am I missing something?

Bubla: the procedure you describe does not completely destroy /etc/group. It removes all users from the admin group, making it impossible to fix the problem afterwards. But this bug has been fixed in the development version, and users-admin will now refuse to overwrite the existing group (just checked both versions).

It seems to me that the current report is about a strange result where most groups are removed, and the newly-created group has GID 0 (reserved to root). So I'd like more informations from Dierk Scharbert, RogerP and fishexe. I know that's difficult to find, though... ;-)

BTW, I found this thread with useful logs, the first detailed data I've ever read about that:
http://ubuntuforums.org/showthread.php?p=6614344

I can confirm this bug is happening. I just spent a couple of hours diagnosing and helping a friend get this fixed. After it was all resolved we were talking and he mentioned he had accessed user and groups the night before. This resulted in his group file being reduced to 3 entries and prevented him from booting. This is a huge bug and i for one have backed up my /etc/group file

Telling us what version you're using would obviously have helped debugging.

Anyway, this kind of behavior is not possible not in Lucid, the new version only changes groups, and will never remove them when creating/modifying an user. It would have been interesting to find out what's going on, but that's kind of obsolete now. If somebody triggers something similar in Lucid, I'm OK to give a look, though.

i don't know if this will help but i just added a new user (already had root and my current user) via users-admin and it basically wiped my /etc/group file. it had 2 lines left in it. luckily i was able to boot in recovery mode and copy the backup at /var/backup/group.bak so that i could boot correctly. I'm still having some other odd errors since my recovery, but that's for a different thread.

I found out about the group backup file from http://ubuntuforums.org/archive/index.php/t-1083487.html and he seems to be having the same problem. I'm running ubuntu 9.04 (jaunty) 64 bit.

if any other system information would help, please ask.

Thanks for your proposal, but as I said I think the changes in Lucid should have fixed that already, but they are too complex to be backported. So I can't help except advising people to switch to Lucid when it's released. If somebody ever reproduces the bug in Lucid I'll have to consider it, but I don't think that will happen.

so what are the plans to fix this error for the 9.04 LTS version? or is it not reproducible for anyone else?

i also found out that my other odd errors are from my mangled /etc/passwd file. what happened is that the System -> Users and Groups basically made my groups file the same as the one attached by fishexe on 2007-11-07 and also changed all my users's groups in my /etc/passwd file to 65534 (nobody) when i added my new unprivileged user. Unfortunately the backup in /var/backups of the passwd file was also mangled.

eg:
  root:x:0:65534:/root:/bin/bash
should be on my system
  root:x:0:0:/root:/bin/bash

i traced this down since i could no longer get into the Users and groups applet to try and reproduce the problem. i would get the error "The configuration could not be loaded" "you are not allowed to access the system configuration"

if i try to add a new unprivileged user with a long password (48 chars in this case) it will basically mess up all my groups as stated above. i just tried it again and it happened again. so for me it's reproducible. is there somewhere i need to go to report this for 9.04 LTS?

sorry for the verbose message but i want anyone else seeing this problem to be able to find this post and fix it.

This bug was fixed in the package gnome-system-tools - 2.29.3-0ubuntu1

---------------
gnome-system-tools (2.29.3-0ubuntu1) lucid; urgency=low

  * New upstream release (LP: #506365)
    - Move to new System Tools Backends protocol (new liboobs API).
      We now only commit changes to one user at a time, reducing the
      risk for dangerous bugs.
    - Include default profiles configuration file (user-profiles.conf).
      Distributors should modify it to suit their needs and send them
      back for inclusion.
    - When creating an user, don't force UID, main group, home directory
      and shell: these parameters are now handled (better) by the platform
      tools (LP: #488158, LP: #313990)
    - Allow removing home directory when deleting an user (LP: #426125).
    - Don't allow deleting the last administrator account, and warn when
      the user is losing its own admin rights. Same for active users
      (LP: #25947, LP: #349453)
    - Don't allow creating a group with an existing GID (LP: #491434)
    - Use UID and GID ranges defined by liboobs, depending on the platform's
      abilities.
    - Clear suggested login entry when Real name is emptied in the new user
      dialog.
    - Change GConf "showall" option to apply only on users. System groups are
      always shown, since they are the most interesting ones.
    - Various UI and string improvements.
    - Change password for current user by running 'passwd', to avoid
      breaking keyrings and encrypted dirs
    - Ask for PolicyKit authentication when it most makes sense, i.e.
      when showing dialogs
    - Option to set encrypted home directories when creating users (on
      platforms that support it) (LP: #302870)
    - When editing one group, only commit changes to that group
    - When changing Real name, update it in the users list (LP: #498970)
    - Select current user on start, and the first one after selected user
      has been deleted
    - Don't force updating configuration twice on start
  * Also fixes LP: #344182, LP: #208057, LP: #188757, LP: #372695,
    LP: #99276, LP: #160862
  * debian/control:
    - Bump liboobs-dev build-dep to 2.29.3
  * debian/gnome-system-tools.install:
    - Don't install debian/profile
    - Install upstream user-profiles.conf instead
  * Delete debian/profiles
  * Refreshed patches:
    - 25_sambashare_group_definition.patch
    - 90_relibtoolize.patch
  * Dropped debian/patches/85_user_gnome_about_me_for_password.patch:
    - The change is obsolete in the new version
  * debian/patches/82_gst-packages-time-admin.patch:
    - Updated to remove superfluous UI file changes, causing focus issues
      in the users-admin password change dialog. Thanks to Will for
      spotting this (LP: #501976)
 -- Chris Coulson <email address hidden> Fri, 05 Feb 2010 15:30:10 +0000

Master5597: do you mean you're able to reproduce this bug consistently when creating an user with a password longer than 48 chars? I've tried to get the same result with a Live CD of 9.04, and I don't get any problem. Could you attach your /etc/passwd and /etc/group files, possibly replacing usernames to protect your privacy?

BTW, 9.04 is not an LTS, so please confirm you really mean 9.04 a.k.a. Jaunty, and not 8.04 LTS, which is Hardy.

These questions are only meant to check that we can't fix this bug with a trivial fix that could go into Hardy, or that would be forth using for Lucid. But normally this is fixed by a more general change in Lucid as of today.

Actually it happens so far with any user name or password. it also happens with a Desktop user and a different user and password. So far it does it every time. So i don't think the 48 char password is the case. I'm setting up a VM at the moment to test it on a clean system. I'll report back when i get that tested. As far as Ubuntu version, i am running 9.04 and i thought it was a LTS my bad, but I'm definitely using jaunty amd64. now my system is tainted by various PPAs but i doubt any of them have updated gnome-system-tools. is there some way to test where my version of gnome-system-tools cam from? if you want a list of installed packages and PPAs let me know.

Since this happens on my system every time I bet this would be a bigger problem if it was everyone. So far I've just found a few isolated reports so I bet it's just some odd conflict. Could this be a problem/conflict with system-tools-backends vs. gnome-system-tools?

Versions:
gnome-system-tools: 2.22.2-0ubuntu4
system-tools-backends: 2.6.0-2ubuntu8

i just went through my updates this morning before i tested adding a user again.

here's how i can reproduce the problem.
steps to reproduce on my system

system->adminstration->Users and Groups

unlock

adduser button

username: test (or test2)
password: test (or test2)
profile: Unprivileged (or desktop)
Password: generate random password

ok button

new group file

root:x:0:
nogroup:x:65534:

new passwd file
root:x:0:65534:root:/root:/bin/bash
daemon:x:1:65534:daemon:/usr/sbin:/bin/sh
bin:x:2:65534:bin:/bin:/bin/sh
sys:x:3:65534:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:65534:games:/usr/games:/bin/sh
man:x:6:65534:man:/var/cache/man:/bin/sh
lp:x:7:65534:lp:/var/spool/lpd:/bin/sh
mail:x:8:65534:mail:/var/mail:/bin/sh
news:x:9:65534:news:/var/spool/news:/bin/sh
uucp:x:10:65534:uucp:/var/spool/uucp:/bin/sh
proxy:x:13:65534:proxy:/bin:/bin/sh
www-data:x:33:65534:www-data:/var/www:/bin/sh
backup:x:34:65534:backup:/var/backups:/bin/sh
list:x:38:65534:Mailing List Manager:/var/list:/bin/sh
irc:x:39:65534:ircd:/var/run/ircd:/bin/sh
gnats:x:41:65534:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
libuuid:x:100:65534::/var/lib/libuuid:/bin/sh
syslog:x:101:65534::/home/syslog:/bin/false
klog:x:102:65534::/home/klog:/bin/false
hplip:x:103:65534:HPLIP system user,,,:/var/run/hplip:/bin/false
avahi-autoipd:x:104:65534:Avahi autoip daemon,,,:/var/lib/avahi-autoipd:/bin/false
gdm:x:105:65534:Gnome Display Manager:/var/lib/gdm:/bin/false
pulse:x:106:65534:PulseAudio daemon,,,:/var/run/pulse:/bin/false
saned:x:107:65534::/home/saned:/bin/false
messagebus:x:108:65534::/var/run/dbus:/bin/false
polkituser:x:109:65534:PolicyKit,,,:/var/run/PolicyKit:/bin/false
avahi:x:110:65534:Avahi mDNS daemon,,,:/var/run/avahi-daemon:/bin/false
haldaemon:x:111:65534:Hardware abstraction layer,,,:/var/run/hald:/bin/false
username:x:1000:65534:username,,,:/home/username:/bin/bash
mysql:x:112:65534:MySQL Server,,,:/var/lib/mysql:/bin/false
ntop:x:113:65534::/var/lib/ntop:/bin/false
sshd:x:114:65534::/var/run/sshd:/usr/sbin/nologin
vde2-net:x:115:65534::/var/run/vde2:/bin/false
tomcat6:...

Thanks for the files. They seem correct to me. I don't think there's any special problem with your versions of gnome-system-tools and system-tools-backends either.

An interesting hint is that you're using a 64 bits system. It may well be that the GID we send to the backends triggers an int overflow in some way, which leads us to pass 65534 for all groups, which become only one group (just a guess). I'd be interested in the results you can get from https://wiki.ubuntu.com/DebuggingGnomeSystemTools ("For Groups" section).

Also, if you manage to reproduce the problem in a virtual box, that would be very interesting. In that case, you should try with Karmic and Lucid, in which the problem might well be fixed.

ok I am still working on the vm, but the logs you had me run were interesting. the users-admin.log just had 40 copies of the line below (each one followed by a blank line):
(users-admin:14023): Liboobs-CRITICAL **: oobs_group_get_gid: assertion `group != NULL' failed

while the critical error caught my eye (grin) i don't know much about oobs. (reading now)

but the stb-groups.log file was much more interesting:
begin::Start of work report.
file_locate_tool_success::Found tool [uname].
file_run_pipe_success::Piping command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/uname -s 2> /dev/null |] for reading.
file_locate_tool_success::Found tool [groupdel].
file_locate_tool_success::Found tool [groupadd].
file_locate_tool_success::Found tool [groupmod].
file_locate_tool_success::Found tool [delgroup].
file_locate_tool_success::Found tool [addgroup].
file_locate_tool_success::Found tool [usermod].
file_locate_tool_success::Found tool [gpasswd].
file_locate_tool_failed::Couldn't find tool [pw].
file_locate_tool_success::Found tool [userdel].
file_locate_tool_success::Found tool [useradd].
file_locate_tool_success::Found tool [adduser].
file_locate_tool_success::Found tool [deluser].
file_locate_tool_success::Found tool [chfn].
file_open_read_success::Reading options from [/etc/group].
file_open_read_success::Reading options from [/etc/login.defs].
number of values does not match type at /usr/lib/perl5/Net/DBus/Binding/Iterator.pm line 606.

line 606 in /usr/lib/perl5/Net/DBus/Binding/Iterator.pm for me is inside the sub append_struct method/function in the perl module.

Ok i tested this with my 64 bit vm, coped over all my files from /etc/apt/sources.list.d/ then ran the script below. after all the updates and installs the add user works as expected on that system. so i really don't know what's messed up with my (and other few other random people on the net's) system. i do appreciate your time on this, but since i know my system is hosed and it's not a greater widespread bug, i don't know if it's worth more of your time chasing. But i would definitely appreciate any insight or pointers you could give me to chase this.

************* begin script ***********
#!/bin/bash
# add all the new keys for the new repos
sudo apt-get update 2> /tmp/keymissing; for key in $(grep "NO_PUBKEY" /tmp/keymissing |sed "s/.*NO_PUBKEY //"); do echo -e "\nProcessing key: $key"; gpg --keyserver subkeys.pgp.net --recv $key && gpg --export --armor $key | sudo apt-key add -; done
# my various updates and settings
sudo apt-get update
sudo apt-get -y --force-yes install medibuntu-keyring
sudo apt-get upgrade -y
sudo apt-get install build-essential make cmake filezilla acroread wine ubuntu-restricted-extras libdvdcss2
sudo apt-get remove flashplugin-* --purge
sudo apt-get install non-free-codecs flashplugin-nonfree
sudo apt-get remove -y icedtea6-plugin openjdk-6-jre openjdk-6-jre-lib gcj
sudo apt-get install --reinstall -y sun-java6-jre sun-java6-plugin sun-java6-fonts
sudo update-alternatives --auto java
sudo update-alternatives --auto xulrunner
sudo apt-get install -y preload

# things for this system to match my other system
sudo dpkg --set-selected. dpkg.list
sudo apt-get -u dselect-upgrade
# EOF

******************* addons to sources list ********************
# debug packages
deb http://ddebs.ubuntu.com jaunty main restricted universe multiverse
deb http://ddebs.ubuntu.com jaunty-updates main restricted universe multiverse
deb http://ddebs.ubuntu.com jaunty-proposed main restricted universe multiverse
deb http://ddebs.ubuntu.com jaunty-security main restricted universe multiverse
# Ubuntu Avant Window Navigator Repository for jaunty
deb http://ppa.launchpad.net/awn-testing/ubuntu jaunty main
deb-src http://ppa.launchpad.net/awn-testing/ubuntu jaunty main
# Ubuntu ClamAv Repository for Jaunty
deb http://ppa.launchpad.net/ubuntu-clamav/ppa/ubuntu jaunty main
# Ubuntu Compiz Repository for jaunty
deb http://ppa.launchpad.net/compiz/ubuntu jaunty main
# Ubuntu Firefox Repository for jaunty
deb http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-daily/ppa/ubuntu jaunty main
deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu jaunty main
# free fonts
deb http://ppa.launchpad.net/corenominal/ubuntu jaunty main
# Ubuntu FreeNX Repository for januty
deb http://ppa.launchpad.net/freenx-team/ppa/ubuntu jaunty main
deb-src http://ppa.launchpad.net/freenx-team/ppa/ubuntu jaunty main
# Ubuntu GetDeb Repository for Jaunty
deb http://archive.getdeb.net/ubuntu jaunty-getdeb apps
# Ubuntu Liferea Repository for jaunty
deb http://ppa.launchpad.net/liferea/ppa/ubuntu jaunty main
deb-src htt...

Thanks for that very valuable information. It may still worth give a deeper look at this, since it seems to hurt people at random, and can still raise issues in Lucid (even if that doesn't destroy your system as now).

So what happens is that the backends have a problem creating group structures that should be sent over D-Bus, which explains the warning "number of values does not match type at /usr/lib/perl5/Net/DBus/Binding/Iterator.pm line 606". Unfortunately, this line is not where the problem happens, but where the D-Bus perl binding detects it, and it must come from the function GroupsConfig.pm::get(). The liboobs warnings are simply the consequence: empty groups are sent, which explains why we remove all of them (or almost) when committing changes.

I don't know if you know a little about perl, but you can try to get more informations by editing your /usr/share/system-tools-backends-2.0/scripts/GroupsConfig.pm. There's a function called get() there, in which it would be interesting to print to debug output all the informations that were retrieved from /etc/group. For example, you can add to the start of the while loop something like:
&Utils::File::run ("echo Group:");
and at the end of the loop:
&Utils::File::run ("echo " . join(" ", @line));
&Utils::File::run ("echo $copy");

Then, reproducing the debugging steps, you'll be able to see what's going on in the log.

even though my perl is a little dusty (haven't used it since college) this is my get in the GroupsConfig.pm.
sub get
{
  my ($self) = @_;
  my $groups, $logindefs;
  $self->SUPER::reset_counter ();

  $groups = Users::Groups::get ();
  $logindefs = &Users::Users::get_logindefs ();

  return ($groups, $$logindefs{"gmin"}, $$logindefs{"gmax"});
}
i don't see any loop there. so i guess you might have meant the Users::Groups::get() so i found /usr/share/system-tools-backends-2.0/scripts/Users/Groups.pm and put the lines in the get() while loop. (it had your line and copy vars) :-)

now the users-admin log really didn't change:
(users-admin:29856): Liboobs-CRITICAL **: oobs_group_get_gid: assertion `group != NULL' failed

now the stb-groups.log has more info. I'm not sure what the Syntax error is, but i copied and pasted your lines into the file, and they look correct to me. but my perl is still cleaning itself off. hehe.

Yes, I meant Users/Groups.pm. The syntax error is actually not a perl message: it comes from the shell because of the parentheses in "ARRAY()". But that's not an issue since we only want to get the message printed.

Everything seems to be fine - at least groups are found and filled correctly. So I suspect two errors: either the list of members is not passed correctly, or the logindefs are wrong.

The former is easy to check too, just add
&Utils::File::run ("echo " . join(".", @a));

The latter not hard either: add something like
&Utils::File::run ("echo Min: $$logindefs{"gmin"}");
&Utils::File::run ("echo Max: $$logindefs{"gmax"}");
before 'return' in GroupsConfig.pm:get().
If there's a problem, then you should check your /etc/login.defs for GID_MIN and GID_MAX entries. But that problem should not happen since default values should be used.

I'm not very familiar with perl, so I'm a little lost with lists becoming arrays then structs. But since we're looking for a relatively rare bug, I don't think that's a plain syntax error. Thanks for your debugging work, and don't hesitate to play with this method to get more details, as you likely know has much as I do about perl.

update: it's fixed, read more to find out how.

ok i added those lines right before the return in get() in the /usr/share/system-tools-backends-2.0/scripts/GroupsConfig.pm file. although i had to change them to:

&Utils::File::run ("echo Min: " . $$logindefs{"gmin"});
&Utils::File::run ("echo Max: " . $$logindefs{"gmax"});

also i assume you wanted me to add the following line to the Users/Groups.pm file

&Utils::File::run ("echo " . join(".", @a));

the new printed out lines are below:

file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo Min: 100 2> /dev/null > /dev/null].
file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo Max: 60000 2> /dev/null > /dev/null].

the 100 and 60000 are the values from my /etc/login.defs file on both my problem system and my VM test system. my /etc/group file on my trouble system has 73 lines in it and the VM test machine has 72 lines.

the line in the groups.pm file usually prints out:

file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/echo 2> /dev/null > /dev/null].

now here's where the fun begins. i was looking at what the @a variable was, and found my problem. What i found out is that one of the lines in my groups file for the 'user_list' parameter was separated by a colon instead of a comma. (the spec says it's group members' usernames, comma-separated) i changed it to a comma and re run my test. this time it worked perfectly. so basically an extra colon on a line caused it to barf hard core and take out my my system. the offending line was:

audio:x:29:pulse:username
it should be
audio:x:29:pulse,username

so my guess there was some bad update sometime that mistakenly put in a colon instead of a comma. since this was the line it could have been a audio update? also this box was running jaunty beta before i upgraded it to jaunty, so it could have been a beta bug that didn't auto-correct it self later. but in any case maybe the perl module for reading that file needs some better error control, or maybe have something that verifies the files are up to spec before it reads them. i dunno.

also i found out that my /etc/gshadow file was also being hosed. fixed that now too. :-)

thanks for all your help, if there's anything i can do to help make sure this doesn't happen to someone else, please let me know.

You rock! Indeed, I had missed that tiny detail too... I must have been introduced by some buggy script, but this must have been fixed a long time ago without anybody noticing this had raised dramatic problems.

So the main culprit here is our very vulnerable code, which did not even bother to consider the 4th item to be the members list: since we used pop(), we were getting the last item, leaving 4 items instead of 5 to the group structure, which the binding didn't really like. Ideally we should check for each field that it's of the right format. At least, UsersConfig seems to be much more resistant since it checks the number of fields.

I've just pushed a one-line fix upstream so that we never get more than the wanted number of fields. In the worst case, the users list is considered empty, but nothing more happens. Anyway, I could check that in Lucid the bug was much less of an issue, since we only commit changes to groups individually: contrary to Karmic, we were seeing no groups at all, so not committing any changes. Now, we even ensure we show the list of groups, and handle the failure more gracefully.

Thank you so much for the help, you're the first in years to have identified the precise cause of the bug! Please go on helping on Ubuntu, we'd be glad to work with you again.

Rationale for SRU: discussed with Chris Coulson on IRC, since the patch is only one line, it's worth backporting to Hardy, Jaunty and Karmic. Intrepid is too close to end of life. This bug destroys the system from the point of view of most users, since it completely prevents from logging in. The origin of the additional ':' is not identified, but this seems to have affected a significant number of people (see Ubuntu forums).

Patch doesn't bring a large risk, since it simply limits the number of fields we read from a line to the expected number, forcing everything else to be considered as usernames, which is harmless in case it's not correct. See
http://git.gnome.org/browse/system-tools-backends-clone/commit/?id=5bad3f88f5e28fd9c1b62e1da6ff062d520ccc61

no Problem, glad i could help. i was also looking at the bug to see how to fix it, but since you've got it, i won't worry about it.

btw, just for curiosity, what is the fix?

The fix (as linked aboved) is simply to ensure split() stops when it has 4 items. That way, we ensure we won't pass more arguments than the D-Bus binding expects, which prevents the script from dying. So the garbage gets packed in the last field, i.e. users that are members of the group. This is not a problem since clients will simply get unknown users with strange names and ignore them.

Ideally, we should check that every field is valid, but for a backport, a one-line fix that works is better. Anyway, if the line is not correct, we can hardly behave better than clearing the list of members of the group.

Master5597: If you want to help, you can just confirm that the fix I suggested actually fixes the bug in your box too, since I haven't checked Jaunty. You can simply make the change by hand from the link I posted above. Thanks!

This happened to me today, and although I was able to restore /etc/group and /etc/gshadow, more things remain broken in my system, for example pulseaudio, networkmanager, bluetooth, policykit, consolekit and (maybe the root cause) dbus... My syslog is being spammed by pulseaudio failing and many tools from system -> administration just segfault. I'm seriously tempted to just format & reinstall...

*cringe* ACK from ubuntu-sru for the 5bad3f... upstream git patch.

Personal commentary, though, is IMO there's something fundamentally broken about zapping all the groups if the dbus backend dies. This seems to be a defective/fragile design to me.

John: That's why in Lucid the protocol has been completely redesigned to accept changes to individual groups/users.

Thanks for clarifying. That makes me sleep a little bit better at night :)

Chris, can you please upload the patch to hardy/jaunty/karmic and check whether it is in lucid? Thanks!

The fix has been released with the system-tools-backends 2.9.3, which are not in Lucid yet (but as I said, that bug isn't really harmful there since we won't remove all groups if the configuration is empty).

Lucid has s-t-b 2.9.4 now, closing lucid task.

I am running lucid with system-tools-backends at 2.9.4 and am seeing errors trying to run any of:
Time and Date
Users and Groups

example:
$ users-admin

(users-admin:12353): Liboobs-WARNING **: There was an unknown error communicating with the backends: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success
$ gksu users-admin
(users-admin:12389): Liboobs-WARNING **: There was an unknown error communicating with the backends: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success
$ gksudo users-admin
(users-admin:12413): Liboobs-WARNING **: There was an unknown error communicating with the backends: Failed to execute program /lib/dbus-1.0/dbus-daemon-launch-helper: Success

I checked and /etc/groups did not appear to be overwritten, but the commands still do not work either from the menu or the command-line.

More info:
# cat /etc/issue
Ubuntu 10.04 LTS \n \l

# uname -m
x86_64

# apt-show-versions gnome-system-tools system-tools-backends
gnome-system-tools/lucid uptodate 2.30.0-0ubuntu2
system-tools-backends/lucid uptodate 2.9.4-0ubuntu1

Again more info.

Don't know if any of this is related but here is messagebus group related info from /etc/group and /etc/passwd:

# grep messagebus /etc/group
messagebus:x:108:
# grep 108 /etc/group
messagebus:x:108:
# grep 108 /etc/passwd
messagebus:x:102:108::/var/run/dbus:/bin/false
haldaemon:x:108:115:Hardware abstraction layer,,,:/var/run/hald:/bin/false

Please don't reopen a fixed bug at random. Why on earth do you believe this is the same problem?! None of the symtoms you describe is similar. It's not because it has high priority that people will fix your bug more quickly. As you said yourself, "I checked and /etc/groups did not appear to be overwritten".

So please file a new report, and add to it the output of
apt-cache policy system-tools-backends liboobs gnome-system-tools
And try reinstalling these packages with
sudo apt-get install --reinstall system-tools-backends liboobs gnome-system-tools

This reminds me of an old bug that was fixed last cycle.

Ok, if you think this is not related I'll be glad to open a new bug. I do think this is the same underlying problem though.

Also:
# apt-show-versions liboobs
liboobs not installed (even not available)

There is no such package.