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
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 Greg Wallace
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
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.
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.
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. This is true. 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. No. You can easily create groups using the YaST Edit and Create Groups and Users and add the group before you actually create the user. When I update my systems (using a separate /home file system), I do a full install, and when creating a user, I also create the group for that user. I do agree
On Wednesday 24 August 2005 9:57 am, James Knott wrote:
that I would prefer that SuSE create users one per group.
--
Jerry Feldman
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
Jos van Kan wrote:
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
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. This means that I, as a member of group users can read the contents of your personal documents in your home directory. 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. 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.
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
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.
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".
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 Wednesday 24 August 2005 21:39, Felix Miata wrote:
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/
Wow!! When I asked my original question I had no idea that it was going to take off in this direction but I'm glad it did. I've always been uncomfortable with the default permissions and access. Felix, even family members need there own privacy and by default this is acknowledged and accepted. The points raised I think have been valid on both sides, but I think that it is time for re-evaluation. It is important to remember the different needs and scenarios. From my point of view, home areas should be private areas by default. Shared group areas can be created and should be such that person working on the file should be the only person with write access by default and collaborative material can be made group writeable by design. This to me would make sense both for my home computer system and for my work environment. Eddie
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
Jon Nelson wrote:
On Wed, 24 Aug 2005, James Knott wrote:
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.
What can be done, is change /etc/skel, so that group members don't automatically have access to other home directories. Also, as I mentioned, use Webmin to create new users, with their own group ID. I find it hard to believe that unique groups are not even an option with Yast, without going through extra steps for each user.
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)
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. 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 jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
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.
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. -- Jerry Feldman
Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
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.
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? jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
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.
I try to keep consistent and to answer one question at a time. the question was not about changing the default but being able to do otherwise... jdd -- pour m'écrire, aller sur: http://www.dodin.net http://valerie.dodin.net http://arvamip.free.fr
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?
On Thu, Aug 25, 2005 at 10:59:07AM -0400, James Knott wrote:
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?
Hmm. This is a useless security measure anyway. If you want every user in a seperate group just use a default umask of 700. And grant access between users using ACLs, they are working pretty well in the meantime. Ciao, Marcus
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 Wednesday, August 24, 2005 @ 9:44 AM, James Knott wrote:
Jos van Kan wrote:
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
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.
This means that I, as a member of group users can read the contents of your personal documents in your home directory.
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.
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.
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. Greg Wallace
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)
Charles philip Chan wrote:
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:
Please don't ruin a good argument with facts. ;-)
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?
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.
--
Jerry Feldman
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.
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.
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. Randall Schulz
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.
James, On Thursday 25 August 2005 05:21, James Knott wrote:
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?
What about ...? What about ...? What about ...? Each scenario carries its own security requirements and necessitates its own security configuration. That's as far as you can go in the way of universal statements.
...
Randall Schulz
participants (11)
-
Charles philip Chan
-
eddieleprince
-
Felix Miata
-
Greg Wallace
-
James Knott
-
jdd sur free
-
Jerry Feldman
-
Jon Nelson
-
Jos van Kan
-
Marcus Meissner
-
Randall R Schulz