To make some item X world-readable, it is not enough for it to have the right permissions: each component of the absolute path leading to it must also have the right permissions. (My understanding, correct me if I'm wrong, is that X itself must have its world-readable (4) bit set, and every directory component in its path must have its world-executable (1) bit set.) What's the simplest way to do this?

FWIW, my best guess would be something like:

function _mkwr {
    chmod o+x $1 || return 0
    parent=$( dirname $1 )
    if [[ $parent = $1 ]]; then return 0; fi
    _mkwr $parent

function mkwr {
    chmod o+Xr $1
    _mkwr $( dirname $1 )
  • 2
    chmod o=+x doesn't make sense. In the chmod syntax, -, =, and + are mutually exclusive operations. They mean, respestively, remove permissions, set exact permissions, and add permissions. – Celada Mar 6 '13 at 23:44

You're right about permissions: each directory component must be world-executable, and the item itself must be world-readable (and probably world-executable as well if it's a directory).

An additional wrinkle is that if the path involves symbolic links, you need to make every intermediate directory that is necessary to resolve the symbolic link world-executable as well.

If you have a symlink-free path, a simple loop can do the job:

make_directory_world_accessible () {
  case $dir in /*) :;; *) dir=$PWD/$dir;; esac
  while [ -n "$dir" ]; do
    chmod a+x "$dir"
    slashes=${dir##*[!/]}; dir=${dir%$slashes}; dir=${dir%/*}

With symbolic links, you need to look up all symbolic links manually and recurse over each directory component. The kernel does that internally but does not expose the process. For example, given a symlink /foo/bar -> one/two/three, not only do you need to make /foo/one and /foo/two public, but you also need to check whether one and two are symlinks and recurse accordingly.

| improve this answer | |
  • When would slashes be non-empty? – kjo Mar 7 '13 at 11:14
  • 1
    @kjo If there are trailing slashes or multiple slashes, e.g. foo/ or foo//bar. – Gilles 'SO- stop being evil' Mar 7 '13 at 13:18
  • That's a really neat idiom for iterating over subpaths, thanks! Just out of curiosity, what's its advantage over dir=$(dirname "$dir") (other than the need to special-case / with the latter method)? – kjo Mar 7 '13 at 14:29
  • 1
    @kjo It's faster on platforms with slow process startup such as Cygwin, which I've had to use lately. There's also an edge case if you have a filename ending with a newline, which the command substitution would eat up. You should get into the habit of writing dirname -- "$dir" to cope with paths that start with - (not a concern here because we're dealing with an absolute path). There's a difference with trailing slashes but it doesn't matter here. – Gilles 'SO- stop being evil' Mar 7 '13 at 15:10

You are partially right. On a directory the x permission signifies the permission to use that directory to get at objects it references. The r right is needed to read the directory, that is, list the names of the objects it references (note that if your permission is r-- you can list the names, but not access the objects; if it is --x you can access the objects as long as you are able to give the right name, but not list them). The w permission means to modify the directory, that is, renaming objects referenced, delete references, or add new ones. Again, this is completely independent of the other permissions.

Another aspect is that there are 3 sets of permissions, for the user, the group, and others (sometimes named ugo). The user set of bits is for the owner of the file, the group for users belonging to the file's group. When checking permissions, if the user trying an access is the file's owner, the user permissions apply. If the user isn't the file's owner, but belongs to the file's group, the group permissions apply. Only if none of the previous cases apply are the other permissions checked.

Note that as the permission bits are completely independent, the above means there can be files to which neither the owner nor the group have access, but others have full permissions. A bit weird, but consistent and simple.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.