Greg, On Wednesday 24 August 2005 01:54, Greg Wallace wrote:

On Wednedsay, August 24, 2005 @ 12:42 AM, eddieleprince wrote:

...

Inspired by Randall Schulz contribution, I would like to ask how would you set the umask (if that is how it is done) so that newly created files/directories keep the group and privileges of the container directory and not necessarily the group of the creator? By way of example, my default group may be "admin" but I want to create files in a directory owned by group "sales". I want that file to be readable by the sales group but I do want to have to do to a chown or chgrp each time I create a file.

Thanks Eddie

chmod g+s directory

That just forces the group of files created within that directory to have the same group as that of the directory. It does not affect their permissions, which follow the usual rules.

Greg Wallace

Randall Schulz

James Knott wrote:

eddieleprince wrote:

...

Inspired by Randall Schulz contribution, I would like to ask how would you set the umask (if that is how it is done) so that newly created files/directories keep the group and privileges of the container directory and not necessarily the group of the creator? By way of example, my default group may be "admin" but I want to create files in a directory owned by group "sales". I want that file to be readable by the sales group but I do want to have to do to a chown or chgrp each time I create a file.

A directory can't be owned by a group, but you can chgrp to that group. Then set the sticky bit, so that any files created will inherit the group ID. This way, when someone creates a file, while it will still be owned by the user, it will get the group's permission. However, the permission bits will still be determined by the file creators umask. He can, however, change the permissions, if necessary.

Forgot to mention, the default configuration in SuSE has everyone in the "users" group and then gives group members read access to all the home directories. In Red Hat, each user is given his own group, which keeps others out of his home directory. To do this in SuSE, you either have to change the user's group after creating the user or use Webmin to create the user. It's also a good idea to change /etc/skel, to remove the group permissions, when a user is created. I have no idea why SuSE fails on this issue, when they're supposed to be so focused on security.

James Knott wrote:

Forgot to mention, the default configuration in SuSE has everyone in the "users" group and then gives group members read access to all the home directories. In Red Hat, each user is given his own group, which keeps others out of his home directory. To do this in SuSE, you either have to change the user's group after creating the user or use Webmin to create the user. It's also a good idea to change /etc/skel, to remove the group permissions, when a user is created. I have no idea why SuSE fails on this issue, when they're supposed to be so focused on security.

I fail to see what this has got to do with security. It completely defeats the group idea to give every user its own group. But if you want to keep everyone out of your files and directories nothing stops you from chmod'ing the lot to y00, y=0..7 Regards, -- Jos van Kan www.josvankan.tk

James Knott wrote:

Jos van Kan wrote:

...

I fail to see what this has got to do with security. It completely defeats the group idea to give every user its own group. But if you want to keep everyone out of your files and directories nothing stops you from chmod'ing the lot to y00, y=0..7

The security problem is that:

a) Every user is a member of users b) In the default install, every member of the groug users has access to the home directory of every other user.

Yes. But that has nothing to do with security. Only if you *allow* rights to the group "users" that group has reading rights. That the default setup allows the group *reading* rights to your documents is just what the group idea is all about. This has nothing to do with security. Nothing prevents you from creating a directory mkdir very_secret_and_personal_documents chmod 700 very_secret_and_personal_documents and no one will be able to even enter that directory. And nothing prevents you from doing chmod -R go -rwx * to disallow all rights to all files and directories except to the user himself. Regards, -- Jos van Kan www.josvankan.tk

James Knott wrote:

Why should group members have access to my files by default.

Because that is the basis of the whole group idea. Apparently you don't want groups. Fine. Regards, -- Jos van Kan www.josvankan.tk

James Knott wrote:

Jos van Kan wrote:

...

James Knott wrote:

...

...

Why should group members have access to my files by default.

...

Because that is the basis of the whole group idea. Apparently you don't want groups. Fine.

No, I'm not opposed to the group idea. What I am opposed to is that others may have access to my own files by default. If I want to open up access to my own files, that should be my option. If I want to set up a directory for sharing, that is what I'd do. To go further with the neighbour idea, I suppose you don't mind your neighbours walking into your home, because they're part of "the group".

I think the closer analogy is the group called family. Other would be the neighborhood and rest of world, not group. Locking all members of your default group out by default is more like having every door inside your house locked by default. -- "Who of you by worrying can add a single hour to his life?" Matthew 6:27 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://members.ij.net/mrmazda/

On Wed, 24 Aug 2005, James Knott wrote:

Jos van Kan wrote:

...

James Knott wrote:

...

Jos van Kan wrote:

...

...

I fail to see what this has got to do with security. It completely defeats the group idea to give every user its own group. But if you want to keep everyone out of your files and directories nothing stops you from chmod'ing the lot to y00, y=0..7

The security problem is that:

a) Every user is a member of users b) In the default install, every member of the groug users has access to the home directory of every other user.

Yes. But that has nothing to do with security. Only if you *allow* rights to the group "users" that group has reading rights. That the default setup allows the group *reading* rights to your documents is just what the group idea is all about. This has nothing to do with security. Nothing prevents you from creating a directory

mkdir very_secret_and_personal_documents chmod 700 very_secret_and_personal_documents

and no one will be able to even enter that directory. And nothing prevents you from doing chmod -R go -rwx * to disallow all rights to all files and directories except to the user himself.

Why should group members have access to my files by default. If I want to stop them I have to change the permissions to my directory.

I feel that this is the crux of the situation. Consider it "secure by default." If I recall properly, Debian could turn the per-user group concept on and off such that when on new users automatically got new groups of the same name and preferably UID==GID. It seems to me that there is no way that SuSE 10.0 is going to be able to be modified to make groups for each user when that user is created, but that is no reason not to try to get that behavior changed for the future. -- Carpe diem - Seize the day. Carp in denim - There's a fish in my pants! Jon Nelson

On 24 Aug 2005, jnelson-suse@jamponi.net wrote:

I feel that this is the crux of the situation. Consider it "secure by default." If I recall properly, Debian could turn the per-user group concept on and off such that when on new users automatically got new groups of the same name and preferably UID==GID.

Yes, user privacy groups. It actually originates from Redhat.

It seems to me that there is no way that SuSE 10.0 is going to be able to be modified to make groups for each user when that user is created,

You are correct. I do use user privacy groups on my system. However I have to do it manually everytime a new user is created.

but that is no reason not to try to get that behavior changed for the future.

One of us should file a feature request, I would like the option for SUSE Linux to do it automatically too. Charles -- linux: because a PC is a terrible thing to waste (ksh@cis.ufl.edu put this on Tshirts in '93)

jdd sur free wrote:

Jon Nelson wrote:

...

make groups for each user when that user is created, but that is no reason not to try to get that behavior changed for the future.

I remember a very old discussion on this subject, it should be possible to find it.

I don't recall the discussion, but it should be up to the sysop to decide how he wants things done, not SuSE.

there where pros and cons...

about permissions, did you look at this (on /etc)?

permissions permissions.easy permissions.paranoid permissions.d/ permissions.local permissions.secure

Those files are for setting various system directories, not default home directories or groups.

Jerry Feldman wrote:

On Wednesday 24 August 2005 5:46 pm, James Knott wrote:

...

I don't recall the discussion, but it should be up to the sysop to decide how he wants things done, not SuSE. This should always be the case, but the issue is how should the default security be set up out of the box, considering the desktop user who may not be familiar with Linux. In an enterprise situation with SLES (or RHEL) it is assumed that the administrator has the requisite set of skills.

As far as I know, there's no way to set up a unique group as a default. It's not even an option in Yast. Instead, you have to create the group and then make it the user's default. Couldn't there be a button that allows that? Or even an option to set, so that it's the default. I don't have a problem with SuSE chosing to do something by default. What I don't like, is the lack of an option to do otherwise.

On Thu, Aug 25, 2005 at 04:01:15PM +0200, jdd sur free wrote:

James Knott wrote:

...

don't have a problem with SuSE chosing to do something by default. What I don't like, is the lack of an option to do otherwise.

This I can understand, but yast can't don anything. However what about adding this to the opensuse wishkist?

You can change the default. Ciao, Marcus

Marcus Meissner wrote:

On Thu, Aug 25, 2005 at 04:01:15PM +0200, jdd sur free wrote:

...

James Knott wrote:

...

don't have a problem with SuSE chosing to do something by default. What I don't like, is the lack of an option to do otherwise. This I can understand, but yast can't don anything. However what about adding this to the opensuse wishkist?

You can change the default.

How? I know how to change the default home permissions and umask, but where do you change the default user group, so that it can be unique?

James Knott wrote:

Jos van Kan wrote:

...

James Knott wrote:

...

Jos van Kan wrote:

...

I fail to see what this has got to do with security. It completely defeats the group idea to give every user its own group. But if you want to keep everyone out of your files and directories nothing stops you from chmod'ing the lot to y00, y=0..7

The security problem is that:

a) Every user is a member of users b) In the default install, every member of the groug users has access to the home directory of every other user.

Yes. But that has nothing to do with security. Only if you *allow* rights to the group "users" that group has reading rights. That the default setup allows the group *reading* rights to your documents is just what the group idea is all about. This has nothing to do with security. Nothing prevents you from creating a directory

mkdir very_secret_and_personal_documents chmod 700 very_secret_and_personal_documents

and no one will be able to even enter that directory. And nothing prevents you from doing chmod -R go -rwx * to disallow all rights to all files and directories except to the user himself.

Why should group members have access to my files by default. If I want to stop them I have to change the permissions to my directory. Shouldn't it be the other way around, that I'd give them acces, only if I wanted them to have it? The way it is right how, it's the same as all your neighbours having the same front door key, so that they can wander in and look around whenever they want.

Further on this. What if you were a member of two or more groups. Should both groups have access to the files of the other groups? If keep all your group files in your home directory, that will happen. However, if you're a member of group A and store the group A's files in a group A directory, then members of group B, who are not also a member of group A, will not have access. If you want group files etc., create a group directory. Do not give group members default access to your home directory.

On 25 Aug 2005, jgregw@acsalaska.net wrote:

Is this a group or permission problem? Maybe the default permissions should be 600? Then you wouldn't necessarily end up with a gazillion groups that may not have any real usefulness.

Here is the rational: http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/ref-guide/s1-users-g... Charles -- "Oh, I've seen copies [of Linux Journal] around the terminal room at The Labs." (By Dennis Ritchie)

Greg Wallace wrote:

Is this a group or permission problem? Maybe the default permissions should be 600? Then you wouldn't necessarily end up with a gazillion groups that may not have any real usefulness.

That's one way around the problem, which I mentioned earlier. As for multiple groups, there are needs for them. For example in a work environment, where there are several projects, each with it's own group of people. There may be some who work in more than one group. However, what would possess SuSE to give everyone access to everyone else's home directory?

Jerry Feldman wrote:

...

Greg Wallace wrote:

...

Is this a group or permission problem? Maybe the default permissions should be 600? Then you wouldn't necessarily end up with a gazillion groups that may not have any real usefulness. That's one way around the problem, which I mentioned earlier. As for multiple groups, there are needs for them. For example in a work environment, where there are several projects, each with it's own group of people. There may be some who work in more than one group. Multiple groups pose no problems. For each project, you add the user ids or each member of that group. When one of these users wants to work within a

On Thursday 25 August 2005 8:18 am, James Knott wrote: project, he/she may use the newgrp(1) command to set the effective group to the desired group.

In general, out of the box, each new user is set up as a member of the users group. If I want to work on a project (say SL), if I am a member of the SL group, all I need to do is: newgrp SL I am now effectively in the group SL, and a new shell process is spawned.

Actually, a better way, is to add a user to the group and apply the sticky bit to the group directory. This way, the user has group access, immediately after logging on and any files created in the group directory can be accessed, according to group priviledges. Also, if you use that newgrp command, what happens when you return to your home directory and create a file there, while still a member of that other group? You've now created a file with group permissions, that you hadn't intended.

Randall R Schulz wrote:

James,

On Wednesday 24 August 2005 10:44, James Knott wrote:

...

...

If you want to share files with the group, create a directory for that group and every member of that group has access to that shared directory. A user shouldn't have to take action, to keep others out of his home directory.

The validity of that claim rests solely on the assumptions you make about the relationships between the users of the system in question.

Well, for my own personal computers, there's no problem. But what about a family system, where mom & dad might not want all there files available to the kids? What about at work, where the home directory is mounted from a server? Should the manager's or HR files be available to everyone?

...

As an experiment, create another user on your system and create a text document in the home directory for that user. Then, log in as yourself and try reading that file. Then log in as that other user and try accessing files in your home directory. Tell me again about the security of that setup.

That so-called "experiment" is not controlled and will tell the person who conducts it only about the incidental aspects of their local configuration, not about anything universal to the use of groups and umask.

What it was intended to show, is that in the default SuSE configuration, any user can read another's home directory. Nothing more.