If a directory "foo" is owned by user A and contains a directory "bar", which is owned by root, user A can simply remove it with rmdir, which is logical, because "foo" is writable by user A.
But if the directory "bar" contains another root-owned file, the directory can't be removed, because files in it must be removed first, so it becomes empty. But "bar" itself is not writable, so it's not possible to remove files in it.
Is there a way around it? Or, convince me otherwise why it's necessary.
Interpretation 1: a directory is a subspace of the filesystem. It can be further subdivided into subsubspaces by creating subdirectories in it. The owner of the directory foo should have control over everything inside the subspace: foo/bar, foo/bar/qux, etc.
Interpretation 2: a directory is a subspace of the filesystem. Every directory is attached to some other directory, called its parent. The owner of the directory foo has control over everything inside the subspace; however, for a subdirectory foo/bar, the owner of foo has control over whether bar can be attached to foo but not over what goes inside bar: only the owner of bar has control over that.
Evidence in favor of interpretation 2: as you've noted, the way permissions work. Also, the fact that some Unix filesystems allow a directory to be attached to more than one parent: this is called having multiple hard links. (Having multiple hard links is common for regular files, but it's usually discouraged or forbidden for directories mainly because of the risk of creating loops, where a directory is its own grandparent N times removed — so you can't get to it from the root directory, which is a very common expectation. There's also the problem of what to do if a directory has 0 hard links but is not empty: since the directory is unattached, you'd want to delete it, but what do you do with its contents?)
Evidence in favor of interpretation 1: in practice, directories do have a single parent and so form a tree structure. And you can't access foo/bar/qux unless you have execute permission on foo as well as bar (well, except that there are somewhat obscure ways to be given access to bar without being given access to foo). So the upper levels do matter.
On a more practical note, in your situation, user A can do
mkdir garbage mv foo/bar garbage/ rmdir foo
mv to circumvent the issue doesn't work for me on Raspbian (haven't tried on any other systems). Furthermore, having researched this issue, I haven't seen the use of mv as a solution mentioned anywhere else. Indeed, based on my understanding of how the permissions work, it makes sense that the mv fails when I've attempted it. Am I missing something? Or has this functionality perhaps changed? @Gilles @PaulHooper
mv? I'm able to use mv to rename the bar directory. Meaning that the mv succeeds as long as I don't try to move bar outside of the current directory or into any other directory. But the example you gave (which moves bar up a directory) doesn't work for me (permission denied). Does the example you gave assume specific conditions other than those specified in the question?
bar up a directory, it moves it to a directory that you own. garbage can be anywhere on the same filesystem, not necessarily a sibling of foo.
Dec 28, 2016 at 22:48
The only way around this would be to use either a setgid or setuid on the parent directory or use an ACL.
Set the directory setgid with
chmod g+s foo
Set a default ACL on it with
setfacl -d -R -m g:group:rwx foo
This sets it as the default ACL on this path. You must mount the filesystem that contains this path with the acl option!
Now tell me why you think you want this.
make install started from root starts building something.
cd ~user && mkdir qqq && touch qqq/qqq I can't get rid of qqq from user by chmod g+s . and rm -Rf qqq.