Bug 135500

It looks just like the duplicate of bug #135475.

I also saw this option in Mandrake/Fedore, but actually I don't know the real benefits.

Of course, you can change the default permissions of new home directories by setting UMASK value in /etc/login.defs - I don't see a necessity to the unique groups.

Thorsten, could you comment?

It is a duplicate.

And the answer from Marcus is still valid: If somebody does not agree with the defaults, he is free to change them. But we will not.

*** This bug has been marked as a duplicate of 135475 ***

You can create a group which will be a default group for all new users (YaST users->Expert Options->Defaults for New Users).

(In reply to comment #3)
> You can create a group which will be a default group for all new users (YaST
> users->Expert Options->Defaults for New Users).
> 
That's not the point. The point is when you create new user called: user1
then Yast2 also automaticaly create a group with name user1, which user 1 is member off. And the permission is by default set to 700.

Next time you create a new user called user2 and now a new group is made with name users2 and the permission is 700.

/home/user1     rwx------ user-id=user1 group-id=user1

/home/user2     rwx------ user-id=user2 group-id=user2

Believe me this is very important. 
And the remark in bug 135475 "Linux is an Opensource operating system and so welcomes sharing of information." 
worried me that mutch, that I start wonder if SUSE Linux take the operating system seriously within commercial environment.

Because of this remark I'm wondering if I have to abandon SUSE linux within our company. We are using lot of fedora, red hat, Mandrake and Suse. redhat and suse are ussualy bought as it's used for customer. 

And what will be the difference? If you set UMASK in /etc/login.defs to 700, you will get the 700 rights for home directories of all new created users. It doesn't matter if the group is unique or not, when there are no rights for other members of the group.


(From YaST point of view, it wouldn't be hard to add a checkbox similar to that in Fedora, e.g. "Create group for this user". But as I wrote before, I do not see the benefit.)

(In reply to comment #5)
> And what will be the difference? If you set UMASK in /etc/login.defs to 700,
> you will get the 700 rights for home directories of all new created users. It
> doesn't matter if the group is unique or not, when there are no rights for
> other members of the group.
> 
> 
> (From YaST point of view, it wouldn't be hard to add a checkbox similar to that
> in Fedora, e.g. "Create group for this user". But as I wrote before, I do not
> see the benefit.)
> 


It always best to minimize the security risk were possible.


The benefit of having an unique group ID for each user are:

Scenario 1:  
Some times you have a situation; where an user (User 1) go on holiday and another user ( User 2) need to have access to some files during that period.  User 1 don't like to give user 2 the password. But in stead change the permission level of the home directory (/home/user1) to 750 or 770. The user at least know it's not good to make permission level 777.  So in the case where all are using the same group ID (users) They can all read what's in /home/user1 directory.  

If every user got it's own unique group ID. User 1 only have to tell the System Administrator to add  User 2 in as member of User 1. And when User 1 is back from holiday or mission. The person just change the permission back on the top level of /home/user1 directory. Or maybe also redo the group membership.


Scenario 2:   
You have now a situation where an application is made that use shared memory. As you know on shared memory there are also the possible to make the same kind of permissions level as on files. But in this case the person have made the application on a Fedora platform and the software engineer think  that all platforms having a unique group ID. And his application need to have shared memory permission 770. In Fedora, Mandrake, Red Hat it won't create any harm. But in Suse Linux where all are using the same group ID. It's possible for someone to make some malicious code,  and  bring into the shared memory.

In fact. If you run the multimedia player: xmms  and from your shell window enter the command: ipcs
you will in fact notice this application has shared memory permission 777. So in fact it's possible to  bring a virus via the xmms player.  With command: ps -eo “%U %G %a” you will get the user and group information.  

And maybe you should ask yourself. When Fedora, Redhat, Mandrake and Knoppix are all using a unique group ID for each user. Could that not be a reason for that. 

Seperate groups do not bring additional benefits.

If users should share data, the administrator can create a group for this exact purpose... It would (as your scenariol above), just one admin interaction.

The problem is also when users are removed... What happens to the groups? Especially if other users could be in them?