users are not added to "users" group

No. /etc/security/group.conf is the wrong place to set this. If we want users to also be added to the 'users' group by default, this should be done by changing the defaults in /etc/adduser.conf, not by using pam_groups.

But I don't see a compelling reason to use this additional group, since nothing else on the system references it. Since this is a rather systemic change, if you think there is a case to be made for adding users to this group, please present that case to the developer community first via the ubuntu-devel-discuss mailing list rather than in a bug report on a particular package.

Hello Steve,

yes, it may be that the adduser maintainer could change his package, adding redundant group configuration to all users. But other than that, some GUI tools don't seem to always rely on adduser (configuration) or even (debian) policy for user and group ids, unfortunately. (It's understood these are other bugs.)

One compelling reason to populate the users group (it is allready present on any debian/ubuntu system) for any user of a *nix like system is collaboration amongst users. Without this stardard *nix procedure users of a system can not work on files together easily. (Inform about file permission usage, Bug #252351)
Actually it would be good to provide a /home/share/users directory with set-guid permissions by default, to expose this functionality to ubuntu users.

The system itself does not need to reference the users group much because it normally does not share write access with users, world read access is enough. On the other hand there is not much reason for users to grand world writeable access to deamons and server processes even to their shared ressources. All the system has to do is to make sure users belong to the users group.

Again, the empty users group may be a regression as IIRC users properly belonged to the users group in the past.

All I can do to improve ubuntu is providing summarized feedback, if feeling like you would need discussion amongst developers before fixing the issue, I would very much appreceate you, maybe just copying my comments and bringing this forward on appropriate lists, etc.

Thank you for improving ubuntu.

I disagree that collaboration among users is a good reason to use the 'users' group. Collaboration is normally much more fine-grained than this; on a system with any significant number of users, you will normally want to collaborate with a subset of these users only. Either custom groups, or filesystem acls, are a much better fit for this.

If you still think this is an important change to make, then it really is better if you bring it up for discussion among the developers instead of me - I'm not likely to be a good advocate for this change, given that I'm opposed to it.

I agree, there are of course much more fine grained methods than the group of all users. And to be honest when adminstering larger systems the users group is probably not good for much more then giving all users write access to some device, or to files that are served on the net. Now, it's not unlikely that, as you are familiar with things like creating groups and adequate directory hierachies or ACLs, we tend to just go directly to what we know exists.

When we think more like a beginner, as new to the GNU of linux, or how we often get to know things, they may not be aquainted with directory and file permissions etc. at first. But if we asume for a moment we see a directory called /home/share/users with a private subdirectory, where all users of a family computer can put stuff for all to update and modify. (Possibly including <group>/writings and <group>/readings subdirs.) It's foreseeable that finer grained group control might come to mind at some point. But then the answer is allready there, too. The next thoughts are special user groups, how the group direcotries are used is already old news then.

In a sense the users group is the only group that can be set up by default, to work with right away and it serves as a seed. It is already there, usable if not just left empty and visible with a users group directory, for human beings to discover the logic of file permissions.

And its a reasonable answer to the question: I can easily share files around the globe, but how do I share files with my honney who has another account on our ubuntu machine at home?

Though, it is a little addition, using pam_group for this should be rather light on ressources and not make any server without users or really large multi-user setups run less perfect. (And keep /etc/group (or ldap etc.) less cluttered.)

As a modern distribution, oriented towards usability, ubuntu of course used pam from the start, it may just feel like a regression for users were able to use unix file permissions that way for ages.

Without the users group the easiest but not recomendable way is to resort to the bad habit of granting world write access.

There is no risk associated with users belonging to the users group, or is there?

Honestly, I did consider fixing "users not belonging to the users group" a non-issue. Just somthing that has been forgotten at some point of time.

I consider the users group as a feature that can be used but does not have to. But if it is to be used it has to be set up to contain all users, there is no other way around it.

Any GUI tool that doesn't use adduser or comply with policy should be fixed or removed from Ubuntu. I agree with Steve that this belongs in adduser, not PAM.

Just to state that I am indifferent wether this is fixed with pam_group or by adding to the default groups in adduser.

pam_group wouldn't intruduce much redundant info and fix existing systems/users, too.

real group memberships would work for cron/at jobs? (But maybe they use pam session I don't know.)

The following wiki page now contains more information and ties together related bugs.
 https://wiki.ubuntu.com/MultiUserManagement

The users group is neccessary to enable seamless system wide collaboration between users.

Finer-grained collaboration is done through groupdirectories of subgroups (groups with a subset of users as members). (see mentioned wiki page)

Whatever your arguments for the users group, this doesn't belong in pam.

Could someone please reassign, and please provide an argument for a solution that may be harder to modify and activate for existing users by admins and control scripts alike.

please don't set invalid instead of giving a reason and reassigning appropriately

A reason was given over a year ago, in <https://bugs.launchpad.net/ubuntu/+source/pam/+bug/253103/comments/3>. You are proposing a behavior change that you should bring up for general discussion with the developers in an appropriate forum, such as ubuntu-devel; and the implementation should not happen in the pam package. Closing again as invalid.

Changing package because the profiles with default groups in ubuntu are currently maintained in g-s-t (not adduser).

I fail to see why it would be a problem with the gst. Wouldn't a line in /etc/adduser.conf be enough? Even if we handle profiles manually, that won't prevent new users from being added to the "users" group if adduser wants to.

As this problem was introduced by commenting out EXTRA_GROUPS in adduser.conf completely instead of just removing the device groups handled by g-s-t, please set importance back to "bug".

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.