Bugzilla – Bug 135500
create a unique group for each new user added by YaST
Last modified: 2005-12-15 14:47:33 UTC
Feature request for when users are created with YaST2 it has the option to create an automatic unique group ID for each user. Similar function as in Mandrake and Fedora. When you create a new user a unique group ID is also created for the new user. And the permission of user's home directory (/home/user) is as follow: rwx------ with unique user and group ID Even though as mentioned in bug 135475 that: "Linux is an Opensource operating system and so welcomes sharing of information." Then it's not how it works in the commercial world. Here are security and privacy very important.
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?