Group names for any non-root user

Currently, other Linux distributions
(1) create a group # and name equal to the logon’s uid# and name. OpenSuse13.2 appears differently.

OpenSuse13.2
(2) Adding a user joins him to group 100 (user) and does not create a group# with the UID of the user .

What is the norm for SUSE, given Ubuntu, Fedora, Centos, Debian follow method one? They do not automatically join a user to group users.

This forces me to put the group rwx to 000, so I have privacy. Alternatively to manually create user groups corresponding to their uid number (ex, 1000, 1001 etc.) and remove users from group 100 (users)

From a security perspective, no standard user should know the contents of my own directories unless I give him/her that permission.

In the GUI tools, can you direct me to the functionality to manage groups and group memberships? Do I need to upload another application?

Leslie
Montreal Canada

On Sun 23 Nov 2014 06:46:01 PM CST, lsatenstein wrote:

Currently, other Linux distributions
(1) create a group # and name equal to the logon’s uid# and name.
OpenSuse13.2 appears differently.

OpenSuse13.2
(2) Adding a user joins him to group 100 (user) and does not create a
group# with the UID of the user .

What is the norm for SUSE, given Ubuntu, Fedora, Centos, Debian follow
method one? They do not automatically join a user to group users.

This forces me to put the group rwx to 000, so I have privacy.
Alternatively to manually create user groups corresponding to their uid
number (ex, 1000, 1001 etc.) and remove users from group 100 (users)

From a security perspective, no standard user should know the contents
of my own directories unless I give him/her that permission.

In the GUI tools, can you direct me to the functionality to manage
groups and group memberships? Do I need to upload another application?

Leslie
Montreal Canada

Hi
YaST -> Security and Users -> User and Group Management.

For openSUSE the way you describe is the norm :wink: Just like openSUSE
doesn’t by default use sudo like others (unless you check the box)…


Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.28-4-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

As far as I know, slackware also uses (2). And, when I last used solaris, that was using (2). I’m guessing that BSD probably uses (2).

Method (2) has been the unix tradition for a long time. I never did understand why some distros change to (1), since it doesn’t actually achieve anything.

All users have the same group ==> groups are not useful.
All users have their own private group ==> groups are not useful.

To make use of groups, you need to be able to create additional groups as needed, and add users to those groups as needed. That’s actually easier to do with method (2), because method (1) clutters the group name space with a lot of useless groups.

This forces me to put the group rwx to 000, so I have privacy. Alternatively to manually create user groups corresponding to their uid number (ex, 1000, 1001 etc.) and remove users from group 100 (users)

If you want privacy, you have to do that anyway for the other permissions. Since you can do it all in the same command, there is no additional effort required.

From a security perspective, no standard user should know the contents of my own directories unless I give him/her that permission.

That’s why there’s a “chmod” command.

I take the opposite attitude. Everything under my home directory should be freely readable by all, unless I restrict (as I do for a few subdirectories such as “PRIVATE” and “Mail”.

The idea is to have easier sharing of files between users in a project. You add user to project group and set SGID bit on project directory so all new files inherit project group. Because every user is in private group by default, umask can be set to open group access, so all project members will have access to any new file. If all users were in the same group by default, umask most likely would be set to restrict group access, making new files created under project directory inaccessible to others.

If there is only one member of the group, then this doesn’t do much.

Because every user is in private group by default, umask can be set to open group access, so all project members will have access to any new file.

And that causes problems with software such as “openssh”, and “sendmail”, which consider group write access to be too lax.