Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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 )
}
share|improve this question
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
    
@Celada: thanks, I've fixed the error. –  kjo Mar 6 '13 at 23:46
add comment

2 Answers

up vote 1 down vote accepted

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 () {
  dir=$1
  case $dir in /*) :;; *) dir=$PWD/$dir;; esac
  while [ -n "$dir" ]; do
    chmod a+x "$dir"
    slashes=${dir##*[!/]}; dir=${dir%$slashes}; dir=${dir%/*}
  done
}

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.

share|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 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 Mar 7 '13 at 15:10
    
Useful advice. Thanks. –  kjo Mar 7 '13 at 15:29
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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