What causes Permission Denied when doing an ls on a symbolic link, when the underlying file has 'r' granted to all?
Solution 1
ls
doesn't care about the permissions of a file because it's only listing its directory entry. However, when ls
dereferences a symbolic link, it is accessing the contents of the link. So it does care about the permissions of the link. Here you don't have the permission to read what the target of libodm10.dylib
is unless you're in the dba
group.
You need to change the permissions of the symbolic link as well. Here there is no reason not to make the link world-readable.
Note that some unices simply don't support permissions on symbolic link; OSX does.
Solution 2
If the execute bit on the parent directory of the file is not on for your user or group then you can't "search" in that directory.
Related videos on Youtube
JulesLt
Updated on September 17, 2022Comments
-
JulesLt almost 2 years
Not sure if this belongs here or on superuser.com.
I'm battling with getting a C process working that needs to link in Oracle dynamic libraries.
It compiles and runs fine under the oracle user (the user oracle was installed against) but not under another account. The obvious reason is that the default oracle install doesn't grant read or execute to any of the shared libraries in /lib
I've granted r+x to all for the underlying dylib (equivalent to .so, etc) and executing under the oracle user I get the following results
ls -lrt *odm* -rwxr-xr-x 1 oracle dba 9000 Mar 3 2009 libodmd10.dylib lrwxrwx--- 1 oracle dba 15 Jul 25 14:23 libodm10.dylib -> libodmd10.dylib
Doing the same under my other user (the one I want to execute under) I get the following
ls -lrt libodmd10.dylib -rwxr-xr-x 1 oracle dba 9000 Mar 3 2009 libodmd10.dylib ls -lrt libodm10.dylib ls: libodm10.dylib: Permission denied lrwxrwx--- 1 oracle dba 15 Jul 25 14:23 libodm10.dylib
I suspect the answer is incredibly dumb and simple, but my understanding was that symbolic links inherited permissions from the underlying file.
-
JulesLt almost 14 yearsThe parent directory is accessible - I can see the target file, which does have r+x set, and can definitely read it. The problem seems restricted to the sym link. Answer below suggests OSX/BSD supports permissions on sym links which is probably the issue - my understanding of inherited permissions doesn't apply.
-
JulesLt almost 14 yearsThanks, this pointed me in the right direction - need to specify -h as an option to chmod in order to change permissions on a link. A good case of prior knowledge of other Unix flavours leading you in the wrong direction - I'm used to the permissions of the underlying being the ones that count.