users are not added to "users" group (empty, broken behaviour)

Bug #549117 reported by ceg on 2010-03-26
26
This bug affects 3 people
Affects Status Importance Assigned to Milestone
NULL Project
Undecided
Unassigned
adduser (Ubuntu)
Undecided
Unassigned
Nominated for Lucid by ceg

Bug Description

Binary package hint: adduser

Current behaviour is:
The "users" group exists but is not populated (empty). When setting up a (set group ID) group directory (i.e. /home/group/users) users can not collaborate on files in that directory.

(This was originally broken because gnome-system-tools introduced its own user profiles without using adduser profiles (different config files) and disabling the EXTRA_GROUPS in adduser.conf alltogether instead of leaving the "users" group untouched.)

Changed (repaired) behaviour would be:
Users are added to the "users" group just as well when the default (private) USERGROUP scheme is used, so that group directories for "users" are functional again.

Two solutions exist to have all (regular/login) users to belong to the users group by default again:

1)
 Centrally add one line to /etc/security/group.conf (for dynamic addition to the group during login):
*; *; *; Al0000-2400; users

2)
 Add all existing users (according to adduser.conf: FIRST_UID / LAST_UID) manually/scripted to the users group and setting EXTRA_GROUPS="users" in adduser.conf for new users.

There should be no security risk involved, because no files belonging to the users group are created by default and at the same time users is applied as the primary group to users when (private) USERGROUPS are disabled in /etc/adduser.conf.

The users group is generally used as a group refering to all users, and it makes the user private group scheme work as designed.

(this issue is filed in the context of https://wiki.ubuntu.com/MultiUserManagement )

ceg (ceg) wrote :

Attaching a simple patch that targets adduser. Please consider it for quick inclusion for the next release to stop creating broken user accounts.

* Re-enables EXTRA_GROUPS="users".
* Its not proposing a new behavior (change) but re-enables standard (and prior) bahaviour.
* If an admin does not want user wide collaboration (or wants it only with finer grained groups) he does not create directories owned by the users group.

For a complete fix, something like a postinst script would need to add existing users to the users group.

Lorenzo De Liso (blackz) on 2010-04-27
tags: added: patch
papukaija (papukaija) wrote :

Confirming, but why create a new bug about this issue?

Changed in adduser (Ubuntu):
status: New → Confirmed
Changed in adduser (Ubuntu):
status: Confirmed → Fix Committed
assignee: nobody → martincloutier (martincloutier)
status: Fix Committed → Fix Released
papukaija (papukaija) wrote :

@martincloutier: Please don't touch at this bug's status without an explanation. Thanks.

Changed in adduser (Ubuntu):
assignee: martincloutier (martincloutier) → nobody
affects: adduser (Ubuntu) → null
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in adduser (Ubuntu):
status: New → Confirmed
papukaija (papukaija) wrote :

@martincloutier: If you consider this bug as not no longer reproducible in Precise, you should state so and mark the bug as incomplete or invalid.

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