users-admin should leave adduser handle main group creation

Funny way of reporting a bug... How can you suspect there's a problem if you don't know whether adduser/deluser are used? ;-)

Can you explain the differences you've spotted with adduser? I'm aware of a few issues that we'd like to fix for the next release, namely that we set the password using usermod, encrypting it ourselves (erk!). We also create the main group manually, which is maybe a bad idea. Else I think we behave the same, since users are created with adduser. Naturally, the user can provide custom settings for home or UID, and we provide user profiles to make this easier, so we can't fully rely on adduser's default for that.

BTW, the part of the Debian policy you quote is not really clear to me, since adduser is not even part of base-passwd. This package only contains config files that won't modify themselves on their own...

Uh, oh, I got that feeling you know ;-)

Seriously, exactly as you write I was seeing the user being added to his primary private group.

"adduser tester" produces this group entry: "tester:x:1006:"
where users-admin produced: "test:x:1005:test"

I had experienced much trouble before because of another tool not using adduser (with its hooks). (probably why I got suspicious so quickly)

Thank you for your response and feedback.

(Strange you're right, maybe adduser once belonged to base-passwd and the doc didn't get updated?)

> Seriously, exactly as you write I was seeing the user being added to his primary private group.
> "adduser tester" produces this group entry: "tester:x:1006:"
> where users-admin produced: "test:x:1005:test"
So I'm happy to find somebody knowing what we should do. I've reported bug 545714 [1] in Debian some time ago, because I didn't understand why main groups were not removed. If you can confirm that users should not be members of their main groups, I can stop forcing this as users-admin has always done, which will fix another issue, and make the bug report much more problematic.

Other than that, what are the complaints that still justify keeping this report open?

1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545714

Concerning the UPG group membership: As it is not necessary (and redundant) and gives problems I believe users should not be made members of their main groups.

As a result of adding the user to its main group deluser thinks the primary group is not one adduser has created automatically as a user private group (UPG) but a manually added group. So the empty group will not be deleted automatically.

However if it truly is a UPG (created off record by users-admin) but is not being deleted together with the user, this in turn may very quickly lead to UPG accounts with primary GID != UID (when a user has been deleted before). Only if, of course, the adduser UID allocation algrithm is implemented in such a way that it does not skip UIDs with taken GIDs, or the calling program makes that decision. (May this be an issue for users-admin or adduser? May need fixing then, the same thing might happen as soon as a group is created manually.)

(Let me stress that my feedback here is merely from a admin/users point of view, not of any knowledge from adduser or useradd which it in turn I believe depends on.)

FYI: I was editing the (UPG) related wiki page https://wiki.ubuntu.com/MultiUserManagement when I got to users-admin. You may like to have a look at. Those kind of informations might be interesting for any users-admin user, and good for its help or wizard texts?

How funny: you linked the wiki spec to the blueprint I had written a few years ago, without knowing how to implement it precisely.

The information from the wiki page would be nice to show from users-admin's help, but 1) our help is pretty outdated now, we should rewrite it from scratch using topic-centered pages (Mallard), 2) this is distro-dependent, so it should be shipped as a patch to the upstream help files (which depends on 1), and 3) I guess it would be good to have a simpler way to set this up than managing groups manually, and this help could be shown there. If one day you get all the bugs you cite fixed, and want to work on a GUI for that, you're welcome! ;-)

Your explanation of UPG makes sense to me, I think I'll simply stop adding the user to its main group. (But still, adduser could be smarter and remove the group if the user was the only member of it.) Though, the wiki page says
> All this can work because the primary group of each user is by default
> a private user group. (With the single member being the user itself.)
Which is in contradiction with what you've just told me. You may want to fix this: there's no member of the group, by default.

Additionally, do you have some references about the fact that main GID != UID would be a problem for standard cases? users-admin has its own "algorithm" to find a good UID/GID (because we were showing it in the GUI before creating the user, implying we had to choose it), which does not check that. If that really matters, I could remove this behavior so that we ask adduser to choose it. This is generally a good idea, but may not be very high priority for me if it does not hurt.

Hi,
what a nice coincidence. :) Thank you for your feedback. I have now updated the wiki to match the adduser behaviour as well.

I've seen now, that only useradd/groupadd is part of the debian passwd package, but adduser uses it.

> (But still, adduser could be smarter and remove the group if the user was the only member of it.)
Imagine the group of santaclauses. Around the end off the year different people get to be members therin. If the manually created group would get deleted with the last santa claus resigning in january, next year a newly created group would probably not get the same GID . Files provided in the /home/group/santaclauses would not be usable by the new group.

I don't know the problems GID != UID UPGs could make other then not being easily recognizable by humans, when seeing the numerical IDs in .tar files or mounts on other machines.

> users-admin has its own "algorithm" to find a good UID/GID
> ...
> If that really matters, I could remove this behavior so that we ask adduser to choose [the UID/GIDs]. This is generally a good idea, but may not be very high priority for me if it does not hurt.

Oh, well, that kind of behaviour however can actually hurt heavily, yes. (another tool has hit me with that) Especially in networked evironments you assign special UID/GID ranges to use (and configure the useradd/adduser hooks to take care of it). Now if me or some other admin of the institution switches the GUI tool and it starts choosing IDs of its own liking the tool can cause quite adverse effects. So if you can, please do not default to override the numerical IDs assigned by the system.

In all I am happy to hear users-admin is generally using the adduser tool, and it's only some avoidable overrides that are troublesome.

BTW: (for forwarding to the debian bug you linked)

the default from /etc/login.defs:
# This enables userdel to remove user groups if no members exist.
#
# Other former uses of this variable such as setting the umask when
# user==primary group are not used in PAM environments, thus in Debian
#
USERGROUPS_ENAB yes

In this case userdel should probaly also alter the "Warning: group
X is now empty." message to "According to USERGROUPS_ENAB yes, the empty private user group has been deleted as well." or somthing.

Actually, now that I think of it, we can't avoid forcing the UID because we implement user profiles in users-admin. Those allow the distribution/admin to present users with typical account types, which set sensible default values for home dir, shell, groups membership (esp. admin), and UID.

It's kind of silly we implement this on the GUI side, but as we can't be sure the distribution supports this kind of feature (and none does ATM), moving this responsibility to adduser would require modifying deeply the protocol, and add fallback support for systems that don't support this. So it's not going to happen soon, given that adduser would have to support that first. Administrators using users-admin should ensure the profiles are correctly defined, or not use the tool at all. All I can do for now is have a look at the profiles handling code so that when no profiles are set, we don't specify any UID, and the backends leave adduser decide for us. Not very hard, but our protocol does not support it ATM.

I'll use this bug to track the issue of not adding users to their main groups. I should be able to fix this soon.

All right, has been a pleasure.

From viewing users I created with adduser I just noticed that in the g-s-t edit group window the users name is of course not checked when viewing any UPG created with adduser.

It may be nice to remove that user from the list and have some sort of indicator that a group is a (possibly private) primary group of user x instead, just as an affirmation that everything is ok.

Another UI thing is that when changing the primary group of user, the g-s-t user may want the (edited) user to stay a member of the prior group. (you probably already had that in mind)

s / remove that user from the list / remove that checkbox from the list

Just came across this answer.
http://lists.alioth.debian.org/pipermail/adduser-devel/2008-February/003161.html

Sure, that would make sense. But that's not really high priority to me, as most people won't tweak the group settings without knowing how this works. Maybe one day...

Good news, I've just finished a future patch that allows us to stop creating the main group ourselves. When creating an user, the backends can now omit the --gid option, and we let adduser (and equivalents) do the work. This is simpler for everyone. Should be in the next release.

Now I need to get a bug in adduser fixed, because if you specify --uid without --gid, and adduser absolutely wants to use the UID as GID for the new main group, which can fail if the free UID we chose was used by a group (this happens on systems where things are a little messed up, but that's not rare). Since we still have to specify the UID (for now at least), adduser should be patched to choose another GID when needed. Not too hard, I guess.

Hmm, seems like adduser wants to ensure UID == UPG-GID?

Maybe g-s-t could offer to choose the next possible ID available, or optionally override the GID and possibly mess up the system?

Yeah, I thought first we might also choose a UID which would also be a free GID. Anyway, that's fixed another way now: with the default profiles configuration file (/etc/gnome-system-tools/user-profiles.conf), we only force group memberships. UID, Home prefix and shells are now determined by adduser, since we didn't really care.

So that is fixed with 2.29.2, which will be uploaded soon in Lucid. adduser task is Invalid.

Good choice I think. Cutting down the settings forced with g-s-t GUI profiles is probably also a good measure for supporting the adduser profiles (or any other system wide profiles).

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