Changing users randomly affects other users and group memberships

Created an attachment (id=5092)
pmount -d /dev/sda1 output

Created an attachment (id=5093)
id output

(In reply to comment #0)

> Having worked through bug #23770 I have tried all the suggestions and am able to
> mount USB drives with the command pmount -d /dev/sda1.

OK, great. Then the pmount side works.

> Actual results: Drives will not auto mount and appear on the desktop. Connot be
> opened via computer menu, delivering error message:
>
> mount: wrong fs type, bad option, bad superblock on /dev/sdb,

Well, that *is* wrong. /dev/sda1 != /dev/sdb.

Can you please do the steps in http://wiki.ubuntu.com/DebuggingRemovableDevices
(only the first half of the page, no hald debug)?

Created an attachment (id=5100)
devices.txt

Created an attachment (id=5101)
dmesg.txt

Created an attachment (id=5102)
gvm.log

Created an attachment (id=5103)
lshal.txt

Output of id

rick@trevor:~$ id
uid=1000(rick) gid=1000(rick)
groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),106(admin),1000(rick)

Rick.....

rick@trevor:~$ uname - a
Linux

(In reply to comment #9)
> rick@trevor:~$ uname - a
> Linux

Hmm, that should be 'uname -a', not '- a' ('mind the gap')

Created an attachment (id=5121)
uname -a output

Rodger that......

Thank you for the debug output. For the records: the kernel correctly recognizes
/dev/sdc and sdc1, pmount can apparently mount it, but hal does only know about
/dev/hdc, not the partition sdc1. I just wonder what happened to sda and sdb.
Did you insert/remove the stick several times?

I need some further information:

  * The output of 'mount' (it's small, no attachment needed)
  * maybe the output of /var/log/kern.log (dmesg only contains the last couple
of kilobytes, and the interesting history has already gone)
  * The same debug information directly after a clean reboot (your computer
appears to be running for about 50 days already)

Thanks

Created an attachment (id=5143)
pre reboot kern.log

Here is the pre reboot mount output, I will post the rebooted stuff then give
you a little background.

rick@trevor:~$ mount
/dev/hda6 on / type reiserfs (rw,notail)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /lib/modules/2.6.12-10-686/volatile type tmpfs (rw,mode=0755)
/dev/hda8 on /home type reiserfs (rw)
/dev/hda1 on /media/windows type ntfs (rw,nls=utf8,umask=0222)
/dev/hda7 on /usr type reiserfs (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
/dev/sda1 on /media/sda1 type vfat
(rw,noexec,nosuid,nodev,quiet,shortname=winnt,uid=1000,gid=1000,umask=077,iocharset=utf8)

Rick....

Post reboot mount output

rick@trevor:~$ mount
/dev/hda6 on / type reiserfs (rw,notail)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /lib/modules/2.6.12-10-686/volatile type tmpfs (rw,mode=0755)
/dev/hda8 on /home type reiserfs (rw)
/dev/hda1 on /media/windows type ntfs (rw,nls=utf8,umask=0222)
/dev/hda7 on /usr type reiserfs (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)

Created an attachment (id=5144)
post reboot kern.log

Hi,

Just a little more information that may help here.

The uptime on my system is rarely more than a couple of days at a time due to a
flakey power supply here.

The USB stick mounting problems are also present for CD/DVDs put into the DVD
drive. These can also be manually mounted with the command

pmount -d /dev/cdrom

and all is hunky dory then.

The USB sticks have been inserted a number of times during the day, each time
mounting with the command

pmount -d /dev/sda1

and unmounting them before removing them (right click, unmount volume)

When mounted as sda1 and navigating to 'places => my computer' sda1 and TAT
CODISK 2.0 appear in the menu, the TAT CODISK 2.0 being unmountable us it is
defined as busy

Hope this helps.

I hope this is a bug and not moronic tendencies on my part!

Rick....

This solved the problem to a large extent:

taken from this thread:

http://www.ubuntuforums.org/showthread.php?t=81836&page=2&highlight=hal+automount+usb+problem

Originally Posted by pbrockway2
Hi,

I've been getting the same error as the OP (Error: given UDI is not a
mountable volume) for about 36 hours. I've been setting up 5.10,
changing lots of things, and don't know at what stage I lost USB access.

Following a suggestion in one of the threads mentioned above, I
had a look at the group membership of the "hal" user. In particular
I set the following rights:
Enable access to external storage devices automatically
Use CD-ROM devices
Use floppy drives

(The thread I was reading referred to actual group names, but these
seemed to correspond).

After a reboot my USB key appeared on the desktop! I hope it stays there
and that this may fix the woes of others - as a "quick fix" checking the hal group
membership beats reformatting the USB key (which I did), or reinstalling
Ubuntu (which I was contemplating)...

Cheers,

Peter

It seems that adding the new user or changing my password (I did both at the
same time affected the permisssions associated with the 'hal' group.

Only thing remaning is associating dvd with totem which is still stuffed up, not
a problem.

Hope this helps somebody and cheers for your time Martin.

Rick....

(In reply to comment #18)

> Following a suggestion in one of the threads mentioned above, I
> had a look at the group membership of the "hal" user. In particular
> I set the following rights:
> Enable access to external storage devices automatically
> Use CD-ROM devices
> Use floppy drives

Hah, that explains a lot, thanks for the research. I added this bit to
https://wiki.ubuntu.com/DebuggingRemovableDevices, so that we can quickly
identify this problem for other people.

Do you have any idea what could have broken the group memberships of the 'hal'
user? Did it work until your Breezy upgrade and immediately broke after upgrading?

This problem was caused by one of the following:

1. Changing user password
2. Adding a new user

This messed up the hal group permissions

Rick....

(In reply to comment #20)

> 2. Adding a new user
>
> This messed up the hal group permissions

This is the most likely cause. Which program did you use to add the new user?
The Gnome one (System -> Administration -> Users and Groups), or the command
line one ('sudo adduser name')?

The user was changed by this method:

The Gnome one (System -> Administration -> Users and Groups)

*** Bug 27689 has been marked as a duplicate of this bug. ***

(In reply to comment #22)
> The user was changed by this method:
> The Gnome one (System -> Administration -> Users and Groups)

I played with that tool for a fair while now (both in Breezy and in Dapper), and
I was not able to reproduce this bug. Can you or anyone else?

Please check with 'id hal' before and after calling users-admin whether hal
still has the correct permissions.

*** Bug 26866 has been marked as a duplicate of this bug. ***

I got solution in here https://launchpad.net/distros/ubuntu/+bug/31341

For the record, installing libpmount0.0 is not, and cannot be the solution for this problem; the installation of this (or any other) package merely seems to trigger some action that seems to make it work again. See bug 31341 for details.

Now there is a recipe for reproduction, I will try that out really soon.

Any progress with this?

I tried very hard to reproduce it, without any success. To all the people who can: please write down a detailled list of actions that lead to this bug, and also describe your environment exactly (breezy/dapper, the user names you are creating/removing, etc.).

devices.txt
dmesg.txt
gvm.log
lshal.txt

id
uid=1000(wlx) gid=1000(wlx) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),104(lpadmin),105(scanner),106(admin),1000(wlx)
id hal
uid=110(hal) gid=110(hal) groups=110(hal),24(cdrom),25(floppy),46(plugdev)
uname -a
Linux cngis 2.6.15-18-686 #1 SMP PREEMPT Thu Mar 9 15:29:22 UTC 2006 i686 GNU/Linux
No other users are created.

@wlx: hal permissions seem to be just fine, so if automounting failed for you, it's a different bug. Your lshal output rings a bell, though. I believe your issue is fixed in the latest hal in dapper. Please confirm and open a new bug if it still fails for you.

So, does anybody have a recipe how to reproduce the original bug here? I. e. the steps that lead to the 'hal' user (or haldaemon in latest dapper) to lose its groups?

Rejecing unnecessary 'Ubuntu' task. the g-system-tools task is enough.

I did not get any further replies, the current gnome-system-tools do not seem to be affected, and there is no recipe for reproduction, so I close this now. Please cry out loudly if you still get the issue, then I will reopen.

Reopening and lifting to critical, since a duplicate (bug 64698) just popped up again.

Please see bug 64698 comment; gnome-system-tools should totally not touch the passwords and properties of *all* users in the system, just the one that was actually modified. Also, there still seems to be a bug in the group membership handling. Just as this bug was about removing hal from all of its normal groups (plugdev, floppy, cdrom), that bug was about removing the user from 'admin'.

David, which Ubuntu version do you use?

Martin,

I appreciate the quick response. I use Dapper Drake - 6.06 LTS.

thanks,

David Green

On 10/10/06, Martin Pitt <email address hidden> wrote:
>
> Please see bug 64698 comment; gnome-system-tools should totally not
> touch the passwords and properties of *all* users in the system, just
> the one that was actually modified. Also, there still seems to be a bug
> in the group membership handling. Just as this bug was about removing
> hal from all of its normal groups (plugdev, floppy, cdrom), that bug was
> about removing the user from 'admin'.
>
> David, which Ubuntu version do you use?
>
> --
> no automounting due to wrong hal group memberships
> https://launchpad.net/bugs/26338
>

Martin,

Something else that concerns me about this bug is that after I was removed
from 'admin' and did not have had admin rights I was able to change root's
password via the User/groups management. I had to do this to be able to su
to root so I could add myself back to 'admin'. At the time figured I'd try
it since it was easier than booting the Live CD. However I should not be
allowed to change root's password, even if I am an admin user.

I can write this up as a separate bug.

thanks,

David Green

On 10/10/06, Martin Pitt <email address hidden> wrote:
>
> Please see bug 64698 comment; gnome-system-tools should totally not
> touch the passwords and properties of *all* users in the system, just
> the one that was actually modified. Also, there still seems to be a bug
> in the group membership handling. Just as this bug was about removing
> hal from all of its normal groups (plugdev, floppy, cdrom), that bug was
> about removing the user from 'admin'.
>
> David, which Ubuntu version do you use?
>
> --
> no automounting due to wrong hal group memberships
> https://launchpad.net/bugs/26338
>

David, your last concern is bug 59946, and in the process of being fixed.

Martin,

Thanks for the update. I'd kinda forgotten about this. :)

David Green

On 12/12/06, Martin Pitt <email address hidden> wrote:
>
> David, your last concern is bug 59946, and in the process of being
> fixed.
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://launchpad.net/bugs/26338
>

This critical bug hasn't been touched in a while. Is it still a problem?

Andrew Ash, this bug is a problem, still.

I use Ubuntu 7.04. I created new user (System -> Administration -> Users and Groups) and later my own user lost administrative power. I will reinstall the SO, but I should notified us.

Still a problem -- I just hosed my system trying to add a user. It basically lost everyone's group membership. That knocked me out of admin, and killed network functionality (especially gaim) because lots of userids should be members of haldaemon, but no longer were. Not knowing who had lost what, I poked around until, by removing and reinstalling dbus and hal (etc.), I got network back. I still don't have audio, because I haven't figured out which groups need what, or what reinstall will fix my /etc/group. I had to reboot to single-user ("recovery") mode to add myself back to admin so I could sudo. What a dreadful bug. Completely unexpected that a simple add user operation would hose the system.

Martin,

Any updates on this bug and when it will be fixed? All I see on Launchpad
is that it has been marked as critical. I am still getting emails from
other users that it is a problem and it seems a pretty critical one.
Because of some of my company requirements until this bug is fixed I can't
use Ubuntu but would like to.

On 12/12/06, Martin Pitt <email address hidden> wrote:
>
> David, your last concern is bug 59946, and in the process of being
> fixed.
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://launchpad.net/bugs/26338
>

=== Summary ===
I've just reviewed the duplicates, and marked a few others as duplicates. The problem seems to be that the graphical users-admin tool has some SEVERE bugs that make a system unusable and insecure. It makes several unintended changes to /etc/group under various conditions, including:
  * stripping group membership from all/many accounts when adding a new user
  * allowing non-admin accounts to change the root password
  * deleting accounts other than the selected one (?)
Bug #64698 has a good statement of one manifestation.

Symptoms include:
  * User no longer in sudoers (because no longer in admin)
  * Network failures (because haldaemon is no longer in appropriate groups)
  * Sound failures (because user and haldaemon are no longer in audio)
  * USB and other devices no longer working (haldaemon again)
  * Gnome login problems (audio? hal? networking?)

Very likely this bug is causing a whole host of mysterious bugs that never got tracked back to /etc/group, because the symptoms are apparently unrelated.

One method to recover:
  * Reboot to "recovery" mode (a.k.a. single-user)
  * Edit /etc/group:
     * add the appropriate accounts to "admin" and "audio" (etc) again
     * add "haldaemon" to: cdrom, floppy, audio, plugdev, powerdev (maybe others, but that's what I found)

I am attaching my reconstructed /etc/group, to help people recover. I _appear_ to have everything working again (sound, network, gnome login, sudo) though I may yet have missed something, or your system may have other bits. It's been slightly anonymized -- users "daffy", "bugs", "marvin" and "donald" are fictitious. Hope this helps.

Other possibilities including reinstalling hal and/or udev to reset those permissions. (sudo aptitude reinstall hal hal-device-manger).

Mind you, I'm deleting "users-admin" from my system for now.

Charles,

Thanks for the updates. It's been at least 8 months since I looked at this
but I guess it is still not fixed. I had to drop Ubuntu since this bug
meant it failed (miserably) my company's security criteria.

thanks again,

David

On 7/12/07, Charles Twardy <email address hidden> wrote:
>
>
> ** Attachment added: "Fixed-up /etc/group file"
> http://launchpadlibrarian.net/8449998/fred2
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://bugs.launchpad.net/bugs/26338
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Hi David,

David Green [2007-07-07 13:00 -0000]:
> Martin,
>
> Any updates on this bug and when it will be fixed? All I see on Launchpad
> is that it has been marked as critical. I am still getting emails from
> other users that it is a problem and it seems a pretty critical one.
> Because of some of my company requirements until this bug is fixed I can't
> use Ubuntu but would like to.

I appreciate that this is a critical thing, but so far still nobody
could give a recipe for reproduction. I have never been able to
replicate this issue, so that we can examine it.

Hmm.... Well it has been a while since I looked at it but all I did to
create the bug was use the GUI user-admin too to reassign a user to a
group. I noticed after that that directories the users should have had
access to they did not. Further investigation showed that they were not in
the groups I'd put them in and I had to reset root's password to be able to
run sudo to fix things.

On 7/16/07, Martin Pitt <email address hidden> wrote:
>
> Hi David,
>
> David Green [2007-07-07 13:00 -0000]:
> > Martin,
> >
> > Any updates on this bug and when it will be fixed? All I see on
> Launchpad
> > is that it has been marked as critical. I am still getting emails from
> > other users that it is a problem and it seems a pretty critical one.
> > Because of some of my company requirements until this bug is fixed I
> can't
> > use Ubuntu but would like to.
>
> I appreciate that this is a critical thing, but so far still nobody
> could give a recipe for reproduction. I have never been able to
> replicate this issue, so that we can examine it.
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://bugs.launchpad.net/bugs/26338
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Likewise, most of the reports did very simple things. I tried to add a new
user. (However, it's also likely that a defunct user of the same name was
in /etc/group or /etc/passwd because once upon a time those had been
copied from another machine.)

But it stands to reason that it doesn't happen all the time,
or developers would have noticed that they lost sudo.

Anyone have a fresh spare machine they can experiment on? Does this happen
from a fresh install? If there's extraneous entries in the files? If
you mix adduser and users-admin? Or useradd?

I'd rather not muck around with my work system, as I'm not convinced I've
localized the damage. My office might be able to dig an old machine out
of storage, but I'm swamped for the next week at least.

-Charles Twardy

On Mon, 16 Jul 2007, David Green wrote:

DG>Hmm.... Well it has been a while since I looked at it but all I did to
DG>create the bug was use the GUI user-admin too to reassign a user to a
DG>group. I noticed after that that directories the users should have had
DG>access to they did not. Further investigation showed that they were not in
DG>the groups I'd put them in and I had to reset root's password to be able to
DG>run sudo to fix things.

--
Charles R. Twardy
<email address hidden>
<email address hidden>

My machine was a fresh Dapper Drake install. The users in question were
all newly created ones. I created users, then created groups. Then I
started adding users to groups. After I exited the admin tool and saved the
changes I went to configure the printer and could not. I tracked it back to
rights issues with root - sudo was failing also. I don't believe it
happens in the command line user admin tools - I used those to undo the
damage.

I recently tried v7.04 as a test drive and it had the same issue.

On 7/16/07, Charles Twardy <email address hidden> wrote:
>
> Likewise, most of the reports did very simple things. I tried to add a new
> user. (However, it's also likely that a defunct user of the same name was
> in /etc/group or /etc/passwd because once upon a time those had been
> copied from another machine.)
>
> But it stands to reason that it doesn't happen all the time,
> or developers would have noticed that they lost sudo.
>
> Anyone have a fresh spare machine they can experiment on? Does this happen
> from a fresh install? If there's extraneous entries in the files? If
> you mix adduser and users-admin? Or useradd?
>
> I'd rather not muck around with my work system, as I'm not convinced I've
> localized the damage. My office might be able to dig an old machine out
> of storage, but I'm swamped for the next week at least.
>
> -Charles Twardy
>
> On Mon, 16 Jul 2007, David Green wrote:
>
> DG>Hmm.... Well it has been a while since I looked at it but all I did to
> DG>create the bug was use the GUI user-admin too to reassign a user to a
> DG>group. I noticed after that that directories the users should have had
> DG>access to they did not. Further investigation showed that they were
> not in
> DG>the groups I'd put them in and I had to reset root's password to be
> able to
> DG>run sudo to fix things.
>
> --
> Charles R. Twardy
> <email address hidden>
> <email address hidden>
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://bugs.launchpad.net/bugs/26338
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Charles Twardy [2007-07-17 1:03 -0000]:
> Anyone have a fresh spare machine they can experiment on? Does this happen
> from a fresh install? If there's extraneous entries in the files? If
> you mix adduser and users-admin? Or useradd?

Doing these experiments, and finding which steps lead to that breakage
starting from a clean installation would be really appreciated,
indeed.

> I'd rather not muck around with my work system, as I'm not convinced I've
> localized the damage. My office might be able to dig an old machine out
> of storage, but I'm swamped for the next week at least.

Using VirtualBox or VMWare with snapshots is an awesome and safe way
of trying it out, BTW.

Is this only a Dapper problem?

I am not having any luck at all reproducing the problem in Gutsy under a VM. I have done 8 trials of various operations, and all did nothing but expected.

Here's an easy test method:

mkdir -p ~/trials/orig
cd ~/trials/orig
cp /etc/passwd .
cp /etc/group .
mkdir ../try1
# do some things in the Users and Groups applet
cd ../try1
cp /etc/passwd .
cp /etc/group .
cd ..

diff -u ./orig/passwd ./try1/passwd
diff -u ./orig/group ./try1/group

Examine results to see if it they make sense according to what you did in the applet. Rinse and repeat. Compare try1 with try2 next, try2 to try3, etc...

Hi
I just installed Xubuntu 7.04 onto an old-ish laptop (that was previously running an old release of slackware linux). The initial install wasn't too painful (aside from problems with the disk partitioner returning failure codes numerously, and the fact that the GUI network configurator didn't seem to accomodate ad-hoc WLAN setup which meant me manually poking at the /etc/network/interfaces file)...

However, I too have just experienced the problem met by various other people in this thread. After the full initial installation, my first port of call was to add a new 'basic' user so that my family could do basic login and have access to web-browsing etc...

so.. i used the GUI tool, went in and selected the add user option, filled out the details of the user then 'OK'd' everything. once i'd done this, i logged out of xfce and then tried to login as the newly created user... i was met with an error trying to log in saying that the account could not be validated.. so i then logged in as my 'initial installation' user account to try see what was going on. After logging in as the initial user.. i tried to run the GUI user accounts tool again.. it prompted me for the administrative password to access the utility.. i put in my usual password and was then met with an error saying that i was not allowed to run this utility... to my horror i subsequently discovered that i could not 'sudo' at all with this account...
what seemed to be particularly drastic is that for some reason I noticed that files in the /etc folder that would normally be root/root (i.e. user/group of root) now seemed to have the ownership of (root/newuser) where newuser was the uid of the account i had just tried to add (which did not get added correctly) with the GUI tool....

as a stop-gap i have booted the live cd and i added my initial login to the sudoers file as an 'ALL=(ALL) ALL' entry.. so i could actually be productive again, and i once again ran the GUI user/group maintenance tool.. upon going in here this time i observed that indeed a new group had been added for the account i tried to set up... trying to remove this made the tool complain that it was an administrator group, therefore i can only imagine that it had relabelled the root group??
i renamed this new group back to 'root' and i tried to add the user once again with the tool and this time it seemed to add the user.

since ubuntu seems 'weird' in its use of the root account and my unfamiliarity with ubuntu, are the files that are retained for administrator access (which are normally root/root on other linux distros) also meant to be root/root in ubuntu? or is the group for these meant to be something else?

p.s. i'm still not sure if this stuff has caused any other havoc at all... but to say such a fundamental tool can screw up so badly is a pretty poor show really.. since i'm not a linux expert i've no idea to what extent it has screwed stuff up and how it may have compromised my system security.

Its not something i plan to spend major amounts of time on as the install was simply to be put on a laptop to allow my family access to internet etc through WLAN... once that is setup i dont plan on touching it much...

Thanks.

I sent this note over to the developer at Ubuntu who owns this bug. He may
or may not be contacting you,

On 9/4/07, zoobloik <email address hidden> wrote:
>
> Hi
> I just installed Xubuntu 7.04 onto an old-ish laptop (that was previously
> running an old release of slackware linux). The initial install wasn't too
> painful (aside from problems with the disk partitioner returning failure
> codes numerously, and the fact that the GUI network configurator didn't seem
> to accomodate ad-hoc WLAN setup which meant me manually poking at the
> /etc/network/interfaces file)...
>
> However, I too have just experienced the problem met by various other
> people in this thread. After the full initial installation, my first
> port of call was to add a new 'basic' user so that my family could do
> basic login and have access to web-browsing etc...
>
> so.. i used the GUI tool, went in and selected the add user option, filled
> out the details of the user then 'OK'd' everything. once i'd done this, i
> logged out of xfce and then tried to login as the newly created user... i
> was met with an error trying to log in saying that the account could not be
> validated.. so i then logged in as my 'initial installation' user account to
> try see what was going on. After logging in as the initial user.. i tried to
> run the GUI user accounts tool again.. it prompted me for the administrative
> password to access the utility.. i put in my usual password and was then met
> with an error saying that i was not allowed to run this utility... to my
> horror i subsequently discovered that i could not 'sudo' at all with this
> account...
> what seemed to be particularly drastic is that for some reason I noticed
> that files in the /etc folder that would normally be root/root (i.e.
> user/group of root) now seemed to have the ownership of (root/newuser) where
> newuser was the uid of the account i had just tried to add (which did not
> get added correctly) with the GUI tool....
>
> as a stop-gap i have booted the live cd and i added my initial login to
> the sudoers file as an 'ALL=(ALL) ALL' entry.. so i could actually be
> productive again, and i once again ran the GUI user/group maintenance tool..
> upon going in here this time i observed that indeed a new group had been
> added for the account i tried to set up... trying to remove this made the
> tool complain that it was an administrator group, therefore i can only
> imagine that it had relabelled the root group??
> i renamed this new group back to 'root' and i tried to add the user once
> again with the tool and this time it seemed to add the user.
>
> since ubuntu seems 'weird' in its use of the root account and my
> unfamiliarity with ubuntu, are the files that are retained for
> administrator access (which are normally root/root on other linux
> distros) also meant to be root/root in ubuntu? or is the group for these
> meant to be something else?
>
> p.s. i'm still not sure if this stuff has caused any other havoc at
> all... but to say such a fundamental tool can screw up so badly is a
> pretty poor show really.. since i'm not a linux expert i've no idea to
> what extent it has screwed stuff up and how i...

I've experienced this bug in the following situation:

at my workplace I've set up several machines running Ubuntu 7.04 and which are
integrated in an Active Domain Network controlled by a Windows Server. I did
this using samba, kerberos and winbind, and now these machines can be used with
local and domain accounts (domain accounts are not listed in /etc/passwd but are
managed by winbind).
To allow some domain accounts to gain administrative privileges I added them
manually to the admin group with 'adduser'.
After that, if you use System -> Administration -> Users and Groups to add a new
user, all the domain users (not local users) which were granted admin rights
will lose their privileges. This happens because they are deleted from the admin
group in /etc/group.
The problem does not occur when using the command line utility (adduser).

I also just downloaded wubi & installed ubuntu 7.04 onto my Windows XP machine and have been using ubuntu for several days. Then thru a terminal window, I used the command line & added some users via adduser. I shutdown my Pc succesfully. The following day, I tried to logon to ubuntu using my regular signon that I created upon installation(which is also the same one that I had been using for several days), I now get, Incorrect username or password. Any help would be appreciated.

First, boot to recovery mode or boot from the CD again. That gives
you root access and you can change passwords using passwd. Also, you
can view /etc/group and /etc/passwd to see if your regular signon was
modified.

Note: no one else here has yet reported a problem with the
*command-line* utilities, so check that the symptoms match, etc.

-crt

On 9/12/07, teach2471 <email address hidden> wrote:
> terminal window, I used the command line & added some users via adduser.
> I shutdown my Pc succesfully. The following day, I tried to logon to
> ubuntu using my regular signon that I created upon installation(which is
> also the same one that I had been using for several days), I now get,
> Incorrect username or password. Any help would be appreciated.

I booted into recovery & changed password. Thanks for the help!
Tom

----------------------------------------> From: <email address hidden>> To: <email address hidden>> Date: Fri, 14 Sep 2007 04:02:42 +0000> Subject: Re: [Bug 26338] Re: Adding a user to a group modifies other users' groups and passwords>> First, boot to recovery mode or boot from the CD again. That gives> you root access and you can change passwords using passwd. Also, you> can view /etc/group and /etc/passwd to see if your regular signon was> modified.>> Note: no one else here has yet reported a problem with the> *command-line* utilities, so check that the symptoms match, etc.>> -crt>> On 9/12/07, teach2471 wrote:>> terminal window, I used the command line & added some users via adduser.>> I shutdown my Pc succesfully. The following day, I tried to logon to>> ubuntu using my regular signon that I created upon installation(which is>> also the same one that I had been using for several days), I now get,>> Incorrect username or password. Any help would be appreciated.>> --> Adding a user to a group modifies other users' groups and passwords> https://bugs.launchpad.net/bugs/26338> You received this bug notification because you are a direct subscriber> of the bug.

_________________________________________________________________
Kick back and relax with hot games and cool activities at the Messenger Café.
http://www.cafemessenger.com?ocid=TXT_TAGLM_SeptWLtagline

----------------------------------------> From: <email address hidden>> To: <email address hidden>> Date: Fri, 28 Sep 2007 20:05:40 +0000> Subject: [Bug 26338] Re: Adding a user to a group modifies other users' groups and passwords>> ** Changed in: gnome-system-tools (Ubuntu)> Target: ubuntu-7.10-beta => ubuntu-7.10-rc>> --> Adding a user to a group modifies other users' groups and passwords> https://bugs.launchpad.net/bugs/26338> You received this bug notification because you are a direct subscriber> of the bug.

Thanks for the Update.

Tom
_________________________________________________________________
Explore the seven wonders of the world
http://search.msn.com/results.aspx?q=7+wonders+world&mkt=en-US&form=QBRE

This is a bug since 2005 for crying out loud. Shouldn't somebody just simply review the whole code in the GUI (which creates this mess in the first place)?

Can people who are affected by this please attach their /etc/login.defs?

OK! Adding a /etc/login.defs for Ubuntu Feisty i686
> uname -a
Linux Athena 2.6.20-16-386 #2 Thu Jun 7 20:16:13 UTC 2007 i686 GNU/Linux

My login.defs
Linux pc000076 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686 GNU/Linux

Since I manually changed some PAM config files for the setup described in comment 57, I'm also including these ones...
Linux pc000076 2.6.20-16-generic #2 SMP Sun Sep 23 19:50:39 UTC 2007 i686 GNU/Linux

@Renzo Bagnati: I think your problem is a different one.

Your AD users don't exist in /etc/passwd and unfortunately, the system-tools-backend only know how to retrieve information from /etc/passwd, so your AD users are considered invalid.

When the "Users and Tools" configuration panel retrieve the members of a group, it only gets the valid ones.
When you modify the group configuration, the whole /etc/group file is rewritten without the "invalid" ones as "Users and Tools" doesn't even know about them.

The same bug should happens with a NIS setup I think.

I think the good solution is to have system-tools-backend use the getent command rather than parse the /etc/passwd file.
But maybe you should file a separate bug for this.

I maybe have found something in system-tools-backend which could explain this weird bug.

system-tools-backends looks at the line number instead of the group name to see if a group have been deleted/added/modified.
Just look at the set function in /usr/share/system-tools-backends-2.0/scripts/Users/Groups.pm

I won't go into details but this behaviour works correctly only the first time.

If you launch users-admin, delete a group and then create a new user (with a new group), system-tools-backends will try to delete another group and will try to rename several groups (which fail because the target group name already exists).

/usr/share/system-tools-backends-2.0/scripts/Users/Users.pm seems to behave the same.

I am not sure this is the cause of this bug, I still don't see in what conditions it could trigger this bug.

In reply to comment 67 (Yann Rouillard):

I don't know if I have to file a separate bug for the behaviour I have described. Maybe some other developer can say that.
After all, the fact is that system-tools-backend is not able to behave correctly as do the command line utilities in all the situations described for this bug.
It seems that no one had problems with "adduser" and "deluser". So my question is: why don't make system-tools-backend act as a simple front-end to that commands? Is there any operation that the command line utilities are not able to do? Or are there other motivations?
By the way, I can confirm that the bug is still present after a fresh installation of gutsy.

Ok I had some time to investigate what I discovered (in comment 68). Still not sure if it's the cause of this bug but I am now able to reliably reproduce a serious similar bug:

1. launch users-admin
2. create a test1 user
3. create a test2 user (with admin rights)
4. create a test3 user
5. delete the test1 user
6. delete the test3 user

Here you go, test2 is no longer in the admin groups.

I opened a bug upstream where I put a detailed explanation: http://bugzilla.gnome.org/show_bug.cgi?id=489187

Yann,

Many thanks.

-Charles

On 10/22/07, Yann Rouillard <email address hidden> wrote:
> Ok I had some time to investigate what I discovered (in comment 68).
> Still not sure if it's the cause of this bug but I am now able to
> reliably reproduce a serious similar bug:
--
Charles R. Twardy
Science is organized knowledge. Wisdom is organized life. ~Kant

My thanks too Yann,

That is more or less what happened to me.

On 10/22/07, Charles Twardy <email address hidden> wrote:
>
> Yann,
>
> Many thanks.
>
> -Charles
>
> On 10/22/07, Yann Rouillard <email address hidden> wrote:
> > Ok I had some time to investigate what I discovered (in comment 68).
> > Still not sure if it's the cause of this bug but I am now able to
> > reliably reproduce a serious similar bug:
> --
> Charles R. Twardy
> Science is organized knowledge. Wisdom is organized life. ~Kant
>
> --
> Adding a user to a group modifies other users' groups and passwords
> https://bugs.launchpad.net/bugs/26338
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Greetings
yesterday after system disk failure, I reinstalled my Debian box. The default enviroment was gdm and gnome. So I proceeded to add some user-accounts. After this and closing the user administration tool rebooted the system to make a change in boot device priority, in bios screen. After this, and booting in debian, I noticed that there was a message saying "chown: root/admin no souch group" or something like this. This one followed by a ton of other messages about udev, groups and so on. Logging as the first user, created during installation, there was a message about the sound server that it was unable to initialize. I decided to reinstall. Succesfull install was followed by full install of kde. So I tried to add users with kusers. This time there was no problem. So I think this is a nasty bug in the user-administration tool of Gnome solely.
In my system there are two disks. One is system disk and the second is home disk. I didn't tried to reproduce the problem, but if you want I can send you detailed system configuration.
Best regards and thank in advance for the permission to post the problem in your list
Andreas

The bug has been resolved upstream, see http://bugzilla.gnome.org/show_bug.cgi?id=489187#c2

The bug has been fixed upstream now

http://svn.gnome.org/viewvc/gnome-system-tools?view=revision&revision=4017 has the changes for gnome 2.20, so this should apply well to Gutsy.

This should be fixed in all previous releases, too, although this will require some more serious backporting.

The upstream bug does fix the first test case (operations within gnome-system-tools only), but not the second. I'll followup on the upstream bug.

@martin: your last case is a dupe of https://bugs.launchpad.net/ubuntu/+source/system-tools-backends/+bug/115957

After discussion with upstream, fixing the second test case (parallel usage of adduser) is too intrusive to fix for stable releases. It will be fixed eventually in Gnome 2.21. So let's confine this SRU to the first test case of only using g-s-t for user administration.

This is the proposed changelog:

gnome-system-tools (2.20.0-0ubuntu2) gutsy-proposed; urgency=low

  * Add debian/patches/23_users_update_model.patch:
    - Update the internal model of users and groups with each operation, so
      that it does not become inconsistent with the real world in /etc/passwd
      and /etc/group.
    - This fixes random errors like "unrelated user was dropped from group
      admin", "deleted a different user than the one selected in users-admin",
      etc.
    - Patch backported from SVN head:
      http://svn.gnome.org/viewvc/gnome-system-tools?view=revision&revision=4017
    - LP: #26338

 -- Martin Pitt <email address hidden> Tue, 13 Nov 2007 11:26:21 +0100

Attaching the corresponding dpatch.

I verified that with this patch the test case is fixed.

The very same dpatch also applies to Feisty. I tested that the erroneous behaviour with the test case below happens, and that the patched package fixes it.

Same for edgy, the patch just needs some minor whitespace adjustments.

I tried to reproduce this bug with the dapper version without success. Dapper has quite a different architecture, there is no sytem-tools-backends yet, and all changes done to users-admin are written to the PAM files atomically at program exit. Also, the code is quite different, so that the patches do not apply at all. Restarting users-admin between adding and removing the users also works correctly for me.

Can someone reproduce this test case on dapper with some variation? Otherwise I will ignore dapper for this SRU.

The changes look good to me, I'm fine with having that uploaded to -proposed for the concerned Ubuntu versisons, thanks to the people who worked on those

Accepted into gutsy/feisty/edgy-proposed, please test. Thank you!

I think dapper is really not affected, thus I close the dapper task.

Can people please test the edgy/feisty/gutsy-proposed versions and give feedback here?

Test successfully completed on Edgy, Feisty, and Gutsy installations

On Edgy:
With gnome-system-tools version 2.15.5-0ubuntu2, executing the test case results in the test2 user being incorrectly deleted and the test3 user remaining.
With gnome-system-tools version 2.15.5-0ubuntu6, executing the test case correctly deletes the test1 and test3 users. The test2 user remains with admin priviledges.

On Feisty:
With gnome-system-tools version 2.18.1-0ubuntu1, executing the test case results in the test2 user being incorrectly deleted and the test3 user remaining.
With gnome-system-tools version 2.18.1-0ubuntu2, executing the test case correctly deletes the test1 and test3 users. The test2 user remains with admin priviledges.

On Gutsy:
With gnome-system-tools version 2.20.0-0ubuntu1, executing the test case results in the test2 user being incorrectly deleted and the test3 user remaining.
With gnome-system-tools version 2.20.0-0ubuntu2, executing the test case correctly deletes the test1 and test3 users. The test2 user remains with admin priviledges.

I have tested gnome-system-tools_2.20.0-0ubuntu2 in gutsy for the situation described in comment 57 (presence of domain users managed by winbind).
As expected, the situation is not changed, since this is to be considered like a second test case.

@renzo: I still think you should open another bug for your case, so your specific issue can be tracked.

Copied to edgy/feisty/gutsy-updates.

As suggested by Yann, I've opened a new bug for the situation described in comment 57:
https://bugs.launchpad.net/ubuntu/+source/gnome-system-tools/+bug/164475

I believe this bug is fixed for hardy in gnome-system-tools 2.21.2.1-0ubuntu1.

Running Intrepid 8.10 i386.

Made the decision of adding another user with admin privileges. However while choosing a name ended up calling this new user "admin".

Stupid decision as it was, I'm to blame entirely, but the Gnome "Users and Groups" accepted without further notice. In the next boot I found out that all my sudo privileges had gone (the group "admin" vanished).

Entered the root terminal, fixed things up (I was happy to find a valid group copy in an old /etc directory, just for comparison), but kept wandering if a dumb decision like mine shouldn't be forbidden, some user names just prohibited.

L M Nicolosi [2009-03-10 3:42 -0000]:
> kept wandering if a dumb decision like mine shouldn't be forbidden,
> some user names just prohibited.

I fully agree, the computer should be perfectly able to detect and
disallow "bad" user names. Since this bug is closed, and unrelated,
could you please file a new bug against gnome-system-tools and tell us
the bug number here? Thank you!

Martin,

In gnome-system-tools found bug #236305 "Creating user with username 'admin' hoses admin group, sudo config", that describes exactly what I faced. Re-posted there, thanks for your reply.