Re: permissions and ownership question

[mike808 <mike808@users.sourceforge.net>]

Kara wrote:
>    chgrp users newdir/ ; chmod 644 newdir/ ; chmod +s newdir/
> ... It's referred to as the "sticky bit".

Jason wrote:
> that's exactly what I wanted to do.  I looked at the man page but there
> was no explanation of the sticky bit.  Thanks for your help.

Actually the above example doesn't set the "sticky bit". Decent OSes will let 
you set it in one whack with 'chmod 1755 newdir'.

Your last command, "chmod +s newdir/" will actually set both the setUID bit 
*and* the setGID bit on the directoy. This is probably NOT what you want.
And it is not the "sticky bit". 

The "sticky bit" is set via the above "chmod 1755 newdir" or via the 
human-readable version, "chmod +t newdir". The "t" refers to "save program 
*text* on swap device". What that meant was that when core memory was _very_ 
expensive, you could, via the filesystems permissions, require that when a 
file was loaded into memory that it would stay there, or "stick" in memory, 
and not be unloaded from swap memory, to be reloaded from disk again on the 
next access.

This only refers to files, however. When a *directory* has this attribute (or 
"sticky bit") set, it means that if a user is allowed to create a file in 
that directory, that the ownership of the file is "sticky", and only that 
user may remove the file. This is exactly what is needed for public incoming 
FTP upload areas. The normal U(ser), G(roup), and O(ther) permissions keep 
them from stepping on each other or writing to each other's files, and the 
sticky bit prevents them from deleting someone else's files.

What you were looking for, was part of what Kara gave (although she added a 
bit more). Setting the setUID bit is probably not a GoodIdea(tm) for things 
like programs. i.e. setuid programs owned as 'root'.

What you wanted was "chmod g+s newdir" or "chmod 2755 newdir". Which just sets 
the setGID bit and the setGID bit *only*.

This is also very useful when you have teams of developers and want only the
team members to have write access, you use umasks of '002' and "chmod 2775 
dir" to force group ownership to the team, even if the user normally is in 
some other default group. Most developers don't bother to "newgrp" when they 
change from project to project, so this neatly keeps everything in place.

The only issue that remains for such an environment is the fact that only the 
owner of a file can change it's permissions - which often happens as you 
check files in and out of a code repository (RCS, CVS, etc.). However, 
because only the owner of the file can change the permissions, other team 
members still can't make it read-only or writable when they check it in/out 
from the code repository. I wish there were a way to allow this other than 
via Samba (for which I wrote patches, but someone else had done the same 
thing two months earlier, but the Samba team was slow to get to the queue, so 
I had no knowledge of the prior patch when I wrote mine).

Anyway, back to permissions. This is all documented in the 'info' file for 
chmod (and not on the man page, just as the man page says so) on Linux 
systems.

From the 'info' page on 'chmod':

Structure of File Permissions
=============================
   There are three kinds of permissions that a user can have for a file:

  1. permission to read the file.  For directories, this means
     permission to list the contents of the directory.

  2. permission to write to (change) the file.  For directories, this
     means permission to create and remove files in the directory.

  3. permission to execute the file (run it as a program).  For
     directories, this means permission to access files in the
     directory.

   There are three categories of users who may have different
permissions to perform any of the above operations on a file:

  1. the file's owner;

  2. other users who are in the file's group;

  3. everyone else.

   Files are given an owner and group when they are created.  Usually
the owner is the current user and the group is the group of the
directory the file is in, but this varies with the operating system, the
filesystem the file is created on, and the way the file is created.  You
can change the owner and group of a file by using the `chown' and
`chgrp' commands.

   In addition to the three sets of three permissions listed above, a
file's permissions have three special components, which affect only
executable files (programs) and, on some systems, directories:

  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 "restriction deletion flag" for the directory.

Mike808/
-- 
() Join the ASCII ribbon campaign against HTML email and Microsoft-specific
/\ attachments. If I wanted to read HTML, I would have visited your website!
Support open standards.


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.