When I tried to simulate the permission system under Linux, some strange things came about.
I created a directory ‘main’ by user ‘normal’, and created directory ‘aha’ which permission is 700 using root.
so the owner of ‘main’ is ‘normal’, if the permission is 755, I can delete ‘aha’ just using ‘normal’ user although its owner is root.
but when i put a file in ‘aha’, everything is changed. I can not remove ‘aha’ due to there’s still a file in it.
so, my question is, since ‘aha’ is 700 by root, how can ‘normal’ know it’s empty or not?
My further question is : what does read permission of a directory really mean?
Think of a UNIX directory as a drawer of index cards in the library catalog.
In order to know what books there are, you need read permission on the “drawer”. In order to create or remove new “books”, you need write permissions (which give you ability to put new cards, or remove existing cards from the drawer). In order to “traverse” the directory to a lower level “sub-drawer”, you need execute permission on the drawer itself.
If you already know that book /foo/bar/baz exists, you don’t need read permissions on
/,/fooor/foo/bar, but you do need execute permissions on all of them.A given book could be referenced by multiple “cards” in the same or separate “drawer” (that’s hard links).
A “card” can reference another card (that’s symlinks). Symlinks could became “dangling” (if the other card is removed).
When a book is not referenced by any card in any of the drawers, it “evaporates” from the library.
Well, one way is to try to remove it. If you succeed, it must have been empty. If it was not empty, “normal” can’t find out anymore than that, since “normal” can’t read the directory, and therefore can’t find how many cards are in that “drawer”, or what they are called.
Update:
Because that’s the definition of the eXecutable bit for directories. Since you can’t reasonably execute a directory, that bit would be wasted otherwise. No, the
.and..files have nothing to to do with the execute bit.