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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
