RE: RM disregards file level permissions and uses directory permissions instead.

[James J. Perry]

Eric and Bob,
   Thanks for your quick and concise responses regarding this behavior.
The solution will provide the responsible groups with a way to set
permissions in the way they want them to work versus the way POSIX
specifies.  

   This is one of the reasons why I love Open Source Software because I
got two authoritative answers within 6 hours versus days for proprietary
paid support systems.

   Thanks again!
   -Jim

-----Original Message-----
From: Bob Proulx [mailto:address@hidden 
Sent: Thursday, April 17, 2008 12:54 AM
To: James J. Perry; address@hidden; Jeff Lightner
Subject: Re: RM disregards file level permissions and uses directory
permissions instead.

Eric Blake wrote:
> According to James J. Perry on 4/16/2008 4:25 PM:
> | We are in the cutover process and one of the DBAs found this
behavior.
> | If testfile1 is owned by usera:group1 in a parent directory with
> | permissions 777 owned by usera:group1, userb:group2 can delete
testfile1
> | even if testfile1 has permissions 600.  Conversely if the same
parent
> | directory has permissions 755 and userb owns testfile2 with 777
> | permissions they cannot delete their own file from that parent
> | directory.
> 
> Yes, and POSIX requires this.  You probably want to set the
directory's
> sticky bit.

Yes.  And maybe.  But I really wanted to explain it a different way.

Things go into containers.  In a Unix filesystem files go into
directories.  The directory is the container for files.  Looking at it
this way it should make sense that when creating, renaming/moving, or
deleting files that it isn't the permission on the file that is
important.  It is the permission on the directory that controls all
directory operations.  The directory is the container that determines
whether you can put things into it or take things out of it.

If the directory is writable then then you can create, rename/move,
delete files in it.  If the directory isn't writable then you can't.
Directories are really just special files that contain entries that
point to other files.

Enter the sticky bit.  This causes special rules to come into play to
restrict the definition of whether something is writable or not.  It
is "sticky" with regards to the classic Unix kernel and locking
executables into swap space.  That doesn't really apply any more but
the name has stuck, pardon the pun.  They needed a bit to indicate
that a shared directory such as /tmp must be writable by everyone but
must also keep everyone apart too.  They reused the sticky bit for
this other behavior.

Permissions on the file control whether you can read or write the
file.  This is unrelated to directory permissions.  This difference
between directory permissions and file permissions is sometimes
confusing to people.

This is the Unix filesystem which has been standardized by POSIX.
Other filesystems exist.  The AFS filesystem is an example of a
filesystem that doesn't use Unix permissions.  AFS uses access control
lists for everything and has a different set of permissions.  I
mention this to illustrate that filesystems implement a security
policy layer.  Not all are the same.  But the Unix filesystem is the
most common one on Unix-like systems and all others are very small
niches only by comparison.

> |  I found this happens on rm version 5.2.1 running on RHEL4
> | and 5.97 running on RHEL5.
> 
> Consider upgrading - the latest stable version is 6.10 (and 6.11 is
due
> out this month).

Changing the rm command won't affect this at all.  This feature has
been stable for decades.  It is controlled by the kernel filesystem
and not by the rm command.

Bob