For the following demonstration, I created a few directories:
$ mkdir read_only
$ mkdir exec_only
$ mkdir r_e
$ touch read_only/cant_open
$ echo foo > read_only/cant_open
$ echo bar > exec_only/cant_find
$ echo baz > r_e/normal
$ chmod 400 read_only/
$ chmod 100 exec_only/
$ chmod 500 r_e/
Read permissions are sufficient to list the contents of the directory: ls(1) can't find details about the file, but it can tell you the name of the file.
$ ls read_only/
ls: cannot access read_only/cant_open: Permission denied
cant_open
But read-only access doesn't let you traverse the directory:
$ cat read_only/cant_open
cat: read_only/cant_open: Permission denied
Execute permissions are sufficient to traverse the directory (including cd), but you can't list the contents:
$ ls exec_only/
ls: cannot open directory exec_only/: Permission denied
Even though you can't get a listing of files in the directory, you can still traverse the directory:
$ cat exec_only/cant_find
bar
Both read and execute permissions work as you expect:
$ ls r_e
normal
$ cat r_e/normal
baz
While it is initially confusing to have permission to list the files in a directory but not be able to do anything with them, and it is also confusing to have permission to do things with files but not be able to list them, it is part of Unix's tradition of simple mechanisms being used for clever things: these two elements alone make it easy to implement Capability-based security. If I were to place a few thousand files in the directory, but only wanted some people to read files meant for them, I could easily pick unguessable filenames, and give out the filenames when people give me money to read the files. :)
Or, maybe you have a dozen clients, and you want them all to have access to a directory of files meant for them. If you place all the client information into a single directory with only execute access, they could never determine your other clients, unless they already know that the other person is a client.
You cannot do this; the initial owner is always the object's creator.
What you can do is set the default ACLs to automatically allow read/write to everyone:
setfacl -m default:u::rwx,default:g::rwx,default:o::rwx /public/all
Also optionally set a default group:
chown :nobody /public/all
chmod g+s /public/all
However, none of these will prevent the owner from changing the permissions later.
An alternative solution is to monitor the directory with inotify (using incron) and automatically run chown on creation. Put this to incrontab:
/public/all IN_CREATE chown nobody:nobody $@/$#; chmod 0666 $@/$#
Best Answer
The meaning of execute permission for a directory is the ability to look up file names inside that directory. Of course, successfully looking up a file name produces a reference to an inode number, but the execute permission has nothing to do with inodes per se.
Without execute permission on the directory, you can't stat, open, rename, delete, or descend into subdirectories inside that directory. The only thing you can do is see the list of which filenames exist, and then only if you have read permission (and read but not execute is a strange set of permissions to have for a directory).
Consider if you have
rw-on a directory. You know that filenamefooexists inside this directory. In order to delete it you need to look it up, and you even need access to the inode (to decrement its link count). For that matter, you need access to the inode in order to tell if it's a directory or not (because if it's a directory,unlinkshould fail andrmdirshould succeed, and the reverse if it's not a directory). But you can't look it up.