zhoulai...@melix 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.)
> f...@ubuntu:~/Unix_Tutorial_8/5$ mkdir test
> f...@ubuntu:~/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.
> f...@ubuntu:~/Unix_Tutorial_8/5$ chmod ugo-rwx test/
> f...@ubuntu:~/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.
> f...@ubuntu:~/Unix_Tutorial_8/5$ rmdir test
> f...@ubuntu:~/Unix_Tutorial_8/5$ ls -l
> total 0
> f...@ubuntu:~/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
