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