Re: Too powerful rmdir

[Bob Proulx]

address@hidden wrote:
> I suppose this is a designing issue or a bug:

Thanks for the report.  But the behavior you describe is not a bug but
simply a misunderstanding.

> You can remove an empty directory as you like, even if you don't have the
> right to read, write nor execute:

The permissions of the parent directory control whether you can remove
a file from within it.  The permissions of the file being removed are
not the controlling factor.  (And a directory is just a special file
and follows the same rules.)

> address@hidden:~/Unix_Tutorial_8/5$ mkdir test
> address@hidden:~/Unix_Tutorial_8/5$ ls -l
> total 4
> drwxr-xr-x 2 fu fu 4096 2009-08-12 06:39 test

You made the directory in '.' and so therefore we know that '.' allows
you to modify (create or destroy) contents in it.

> address@hidden:~/Unix_Tutorial_8/5$ chmod ugo-rwx test/
> address@hidden:~/Unix_Tutorial_8/5$ ls -l
> total 4
> d--------- 2 fu fu 4096 2009-08-12 06:39 test

The permissions on that target file are not a controlling factor in
whether you can remove it from its parent directory.  The permissions
on the parent directory control whether you can create or remove files
from the parent directory.

> address@hidden:~/Unix_Tutorial_8/5$ rmdir test
> address@hidden:~/Unix_Tutorial_8/5$ ls -l
> total 0
> address@hidden:~/Unix_Tutorial_8/5$

All correct.  And I am compelled to note that this is all as per
traditional unix filesystem behavior for 40 years.

If you want to prevent a file from being removed (or created) then you
must remove write permission from the directory containing it.

Try this:

  $ mkdir test
  $ chmod a-w .
  $ rmdir test
  rmdir: failed to remove `test': Permission denied

In any case, even if this wasn't so, it is the kernel that enforces
permissions *not* an individual userspace command.  Otherwise all it
would take to circumvent the permissions would be to use perl.

  perl -e 'rmdir("somedir");unlink("somefile");'

Bob