[users-admin] should warn the user of what he's doing when unselecting the administration group

Bug #25947 reported by Kai-Steffen Marks on 2005-11-19
32
Affects Status Importance Assigned to Milestone
GST
Fix Released
Medium
gnome-system-tools (Baltix)
Undecided
Unassigned
gnome-system-tools (Ubuntu)
Medium
Ubuntu Desktop Bugs

Bug Description

When you haven't activated the possibility to login as a root user under the
security tab of the settings of the Gnome Login Manager and/or you haven't given
the root user a real password, replacing the randomly created, you won't be able
to make administrative tasks under the graphical enivoronment. When you try to
do such tasks without administration rights a window asking for the password
pops up. If you enter the wrong one (from the normal user) he will tell you and
shut down the application. If you try again it tries to load the application but
in the end nothing happens. If the password was right on the first try however,
I think the whole program is greyed out and shuts down soon with another error
(I can't remember really). This bugs results in that you can't change any system
settings anymore without commandline (and that is pretty impossible for
inexperienced Linux users like me!), so I had to reinstall the whole system. I
think here should at least appear a text window in which stands that you don't
have the administrative rights to access this program or you would have to enter
the root password.

In my head the password system should get changed, the root password should be
used for global settings (Installing packages) and the normal user password for
local ones (i.e. Network, New Session, mount). The system under Debian made more
sense for me.

I use Breezy Badger stable. The version of the gnome-system-tools I have
installed is 1.40-0ubuntu10.

Sebastien Bacher (seb128) wrote :

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

Sebastien Bacher (seb128) wrote :

Thanks for your bug. The description is not really clear. Is your issue "if you
remove the default user from the admin group you can't do administrative tasks"?

(In reply to comment #2)
> Thanks for your bug. The description is not really clear. Is your issue "if you
> remove the default user from the admin group you can't do administrative tasks"?

Well, under the "user rights" tab of any user in "Users&Groups" there`s this
option called "execute administrator tasks". If you deactivate it these problems
may be the result.
Don`t know more to add.

Sebastien Bacher (seb128) wrote :

Reopening since there is a reply to the comment but it works fine on my computer

Phil Housley (undeconstructed) wrote :

I think the point is simply that if you have no users in the sudo group, you can't do anything as root anymore. I'm not about to try it out now, but I would imagine logging in to recovery mode would get around the problem.

A nice solution would be to check if the sudo group has any members left whenever:
* Trying to delete a user
* Trying to remove a user from a group

If the action would leave the sudo group empty, deny the action.

I've forwarded the issue upstream: http://bugzilla.gnome.org/show_bug.cgi?id=343194

Changed in gnome-system-tools:
assignee: seb128 → desktop-bugs
Harrison Metzger (harrisonmetz) wrote :

I have posted a patch on the upsteam gnome bugzilla. Its not as fancy as Phil's suggestion, but it will warn each user when removing themselves from the admin group. If you think its needed I could add a system that will check root pw is not empty or atleast one user is in the admins group. But this will get difficulty if people make manual changes. What if someone manually modifies the sudoers file and hard codes their name into it. If this would have to parse the sudo file than you would need to know how its organized and if they changed sudo you would need to change g-s-t too. Also, if you had a libsudo to read it for you, this would introduce more dependencies into the package. I fell its best just to warn if you are deselecting your admin privs and prevent user's from deleting their account. If they really wanted to delete their account they could log in as root and delete it there.

Anyway, I have included the patch but please read more about it at upstream bugzilla.

Changed in gnome-system-tools:
status: Confirmed → Triaged
Sebastien Bacher (seb128) wrote :

Thank you for the patch, I've set milestoned the bug so we will review it before gutsy

Changed in gnome-system-tools (Ubuntu):
milestone: ubuntu-7.10-rc → none
Changed in gst:
status: New → Incomplete
Changed in gst:
status: Incomplete → In Progress

This is fixed upstream now.

Changed in gnome-system-tools (Ubuntu):
status: Triaged → Fix Committed

This is not committed in Ubuntu. It's committed upstream, waiting for a release upstream (2.29.2) to be committed on Ubuntu's Baazar repository, and then released in Lucid. See https://wiki.ubuntu.com/Bugs/Status.

Thanks for helping, though! ;-)

Changed in gnome-system-tools (Ubuntu):
status: Fix Committed → Triaged

Milan, I know that (as far as the wiki is concerned) "fix committed" is the wrong status here, but it is frequently used to make searching for bugs that are actually fixed upstream easier. In Addition, the bug watches for the Gnome bug tracker are now out of sync for several month which makes it even harder to keep track of fixed bugs and which causes additional work (this should get better with the fix of bug #383467). I hope you can understand that and don't mind me setting back the status to "fix committed". Thanks.

Changed in gnome-system-tools (Ubuntu):
status: Triaged → Fix Committed

I've no personal problem with that, but if we don't respect what we write on the Wiki, we may as well change it instead of using inconsistent statuses. Don't worry about the wrong upstream status for that, I always go over all bugs registered in the GNOME System Tools Launchpad project (i.e. for upstream) after I've made a release and it's been packaged in Ubuntu. So I'll close it when it's uploaded anyway.

This is fixed in 2.29.2, even if Launchpad doesn't show it.

Launchpad Janitor (janitor) wrote :

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

Changed in gnome-system-tools (Ubuntu):
status: Fix Committed → Fix Released
Changed in gst:
importance: Unknown → Medium
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.