Mailinglist Archive: opensuse (2700 mails)

< Previous Next >
RE: [SLE] File/Directory Permissions.
  • From: "Greg Wallace" <jgregw@xxxxxxxxxxxxx>
  • Date: Thu, 28 Jul 2005 21:11:25 -0800
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.
>> assuming then that when you have "s" (chmod g+s) so you get a permission
>> drwxrwsr-- all the sub directories and files that are created will get
>> same permissions and be accessible to other users in the group?

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

>File:, 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.

>- --
> 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

< Previous Next >