Jay Paulson wrote:

...

Jay Paulson wrote:

...

Quick question about file permissions. I was wondering what the command line was for setting a directory so that users of the same group can read, write, and execute a file. Also, I was wondering what the command line was for when setting a directory permission/ownership was so that anyone in the group can write to the directory. I thought it had something to do with the sticky bit however, I'm not sure what the sticky bit does. man chmod, chown & chgrp

I've read those and I'm still asking. eek! :) What I'm trying to do is have 2 users in the same group able to edit files of other users in the same group or write files in other user's directories as long as they are in the same group.

For example... I have user A in group users and www. User B is in only group www. I have a directory who's owner is user B with a group ownership of www. However, when user A tries to move files into that directory or edit any files in that directory they can't. They can only see the files because the global permission on the directory and files are set to read only.

I really want to figure out how to get user A and user B to be able to work in the same directory as long as they are in the same group. It shouldn't matter who owns the file as long as the users are in the same group.

With SuSE, all users are by default part of the users group. So, all you have to do, is make sure the group has appropriate privilidges for what you want to allow. It may be easiest to use the octal method for chmod. In this way, the three numbers correspond to User, Group and Others. The individual bits are Read, Write and Execute. So, all privilidges would be 7, read & write 6, etc. BTW, you don't have to reply to both the person and the list. Just to the list is fine.

...

I've read those and I'm still asking. eek! :) What I'm trying to do is have 2 users in the same group able to edit files of other users in the same group or write files in other user's directories as long as they are in the same group.

...

For example... I have user A in group users and www. User B is in only group www. I have a directory who's owner is user B with a group ownership of www. However, when user A tries to move files into that directory or edit any files in that directory they can't. They can only see the files because the global permission on the directory and files are set to read only.

...

I really want to figure out how to get user A and user B to be able to work in the same directory as long as they are in the same group. It shouldn't matter who owns the file as long as the users are in the same group.

...

I hope that explains what I'm trying to do.

...

Thanks!

chmod g+rwx /directory

This basically says add read and write privileges for anyone in the group to that directory. X means access for directories, meaning all users in the group can specify it in a file path (for files, x means executable; i. e., it's a program).

Greg Wallace

That helps a ton. I did not know that's what X meant for a directory. I'm assuming then that when you have "s" (chmod g+s) so you get a permission of drwxrwsr-- all the sub directories and files that are created will get the same permissions and be accessible to other users in the group? thanks!

On Thursday, July 28, 2005 @ 3:56 PM, Carlos Robinson wrote:

The Thursday 2005-07-28 at 08:58 -0500, Jay Paulson wrote:

...

That helps a ton. I did not know that's what X meant for a directory. I'm assuming then that when you have "s" (chmod g+s) so you get a permission of drwxrwsr-- all the sub directories and files that are created will get the same permissions and be accessible to other users in the group?

The info page says about the group "s" bit (point 2 below):

File: coreutils.info, Node: Mode Structure

26.1 Structure of File Permissions ==================================

...

1. set the process's effective user ID to that of the file upon execution (called the "setuid bit"). No effect on directories.

2. set the process's effective group ID to that of the file upon execution (called the "setgid bit"). For directories on some systems, put files created in the directory into the same group as the directory, no matter what group the user who creates them is in.

3. save the program's text image on the swap device so it will load more quickly when run (called the "sticky bit"). For directories on some systems, prevent users from removing or renaming a file in a directory unless they own the file or the directory; this is called the "restricted deletion flag" for the directory.

It doesn't say what you thought.

- -- Cheers, Carlos Robinson I just did some experimenting with the s permission at group level on a directory. Looks like, if you have that set, any files you create under that directory automatically get assigned the group from the directory instead of the group you're currently running under. This is great! I added this permission to my Samba share so that any new files I add to it will automatically pick up the share directory. I've had to change those manually in the past. I had thought that s was the sticky bit, but, based on the man pages, t is the sticky bit code for GNU. Also, based on my reading of the man pages, s on "user" permissions for a file says that that program will execute with the privileges of the file "user"/owner as opposed to the user who is running the program. Also, "the Linux kernel ignores the sticky bit on files", and, paraphrasing, for directories, if the sticky bit is set, only the owner of any particular file in that directory can delete or rename it (as opposed to anyone who has general write access to that directory).

Greg Wallace