In order to access a file or directory, you have to have execute access to its parent directory (and therefore all parents above it).
Therefore, if I can access '/var/www/html', then I implicitly can also access
/. That doesn't mean I can do much with it, though, because my to any other subtree is determined by the permission on that directory.
So while while I can get to
/var/www/html, that doesn't mean that I can get to
/var/www/docs -- it depends on the permissions on
Now, here's the important detail for file permissions, and once you understand this, you can craft a reasonable permissions set:
- read: Means you have access to open the file read-only and access its contents
- write: Means you have access to open an existing file read-write and modify or delete its contents. It doesn't mean you can delete the file entry, but you can truncate the file to empty, or change it to say something else.
- execute: means you have permission to run the file. You may not see its contents because the OS will read the file on your behalf and execute it for you.
- read: means you have access to list the files in a directory. You may not have access to do anything with them, but you can at least see their names, sizes, permissions, etc.
- write: means you have access to change the list of files in a directory. That is, you can create files, delete them, rename them, etc. You may not be able to open (read or write) any existing files, but you can modify the list.
- execute: means you can access the files or directories instead the directory as long as you know the name and have the appropriate permissions on the child file or dir. You can use the directory, but you don't have permission to modify or see the list of files.
So to access a given child directory, all you need is the execute bit. So on
/home/ for example, it's not uncommon to see the permissions set to
rwx--x--x and owned by root, with users directories set to
rwx------ and owned by the user. This gives each user access to his own directory, but he can't access or even list the other directories under
An even better system, which is still in development but is stable enough for early adopters, is to use Linux cgroups to give each user or site or program its own filesystem entirely. This is done using a combination of
mount --bind and often unionizing filesystems (like unionfs or aufs) to give each process access to only the files it needs, without unnecessary duplication.
Furthermore, cgroups allow individual processes to live on isolated networks with isolate memory and socket domains and similar resources. This creates the potential for what looks and acts a lot like a virtual machine, but without the virtual machine. This technology is still advancing, but it's pretty clear that this is going to be the way forward for process isolation in Linux.
Relevant projects using this technology include LXC and Docker, offers a very user-friendly way of setting up isolated containers which include their whole "world" from an execution perspective (much like a VM), but without adding virtualization overhead.