I have this file structure:

>> CONTROLLER (@JuniorProgrammers)
>> MODELS (symlink to SHARED/MODELS)
>> VIEWS (@Designers)
>> CONTROLLER (@JuniorProgrammers)
>> MODELS (symlink to SHARED/MODELS)
>> VIEWS (@Designers)
>> MODELS (@SeniorProgrammers)

I need php to be able to read Folder 1.1 contents, but programmers who FTP into Folder 1 won't be able to read the symlink (they CAN see the symlink, but not FOLLOW it including all reads, and writes).

The @ is the groups of users that have read/write access of each layer.

  • Is that not the default behavior? If not, look for a chrooting option in your FTP configuration. This basically causes FTP users to enter a chroot environment with their home directory as root. Provided that folder 2.1 isn't below folder 1 in the hierarchy, the symlink will be broken as far as they're concerned.
    – Joseph R.
    Jun 8, 2013 at 19:45
  • Access rights were invented to solve this kind of problem. But you don't give the necessary information to assess the situation. Jun 8, 2013 at 21:36
  • @HaukeLaging, does this help?
    – Bradley
    Jun 9, 2013 at 0:49
  • Sometimes the answers are suboptimal because the knowledge level of the questioner is estimated wrongly... Are you familiar with chown, chgrp, chmod, and setfacl? Jun 9, 2013 at 1:25
  • Chown, Grgrp, Chmod, Yes. I use them all the time. Haven't used setfacl, reading up on it now, looks like that's the command I'm missing.
    – Bradley
    Jun 9, 2013 at 1:28

2 Answers 2


Symlinks themselves have 777 because in Unix, file security is judged on a file/inode basis. If it's the same data they're operating on, it should have the same security conditions, regardless of the name you gave the system to open it.

[root@hypervisor test]# ls -l
total 0
lrwxrwxrwx. 1 root root 10 Jun  8 16:01 symTest -> /etc/fstab
[root@hypervisor test]# chmod o-rwx symTest
[root@hypervisor test]# ls -l
total 0
lrwxrwxrwx. 1 root root 10 Jun  8 16:01 symTest -> /etc/fstab
[root@hypervisor test]# :-(

Since permissions are set on the inode, it won't work with hard links even:

[root@hypervisor test]# echo "Don't Test Me, Bro" > testing123
[root@hypervisor test]# ls -l
total 4
lrwxrwxrwx. 1 root root 10 Jun  8 16:01 symTest -> /etc/fstab
-rw-r--r--. 1 root root 19 Jun  8 16:06 testing123
[root@hypervisor test]# ln testing123 newHardLink
[root@hypervisor test]# ls -l
total 8
-rw-r--r--. 2 root root 19 Jun  8 16:06 newHardLink
lrwxrwxrwx. 1 root root 10 Jun  8 16:01 symTest -> /etc/fstab
-rw-r--r--. 2 root root 19 Jun  8 16:06 testing123
[root@hypervisor test]# chmod 770 testing123
[root@hypervisor test]# chmod 700 newHardLink
[root@hypervisor test]# ls -lh
total 8.0K
-rwx------. 2 root root 19 Jun  8 16:06 newHardLink
lrwxrwxrwx. 1 root root 10 Jun  8 16:01 symTest -> /etc/fstab
-rwx------. 2 root root 19 Jun  8 16:06 testing123

A symlink isn't an inode (which actually stores the data you're wanting to secure) ergo in the Unix model it complicates things by having two different sets of permissions for protecting the same data.

It sounds like this is an attempt to give different groups of people different levels of access rights to the same file. If that's the case you're actually supposed to use POSIX ACL's (via setfacl and getfacl) to give the files appropriate permissions on the target of the symlink.


To elaborate on the direction you're probably wanting to go in, it's something like:

# setfacl -m u:apache:r-- "Folder 2.1"
# setfacl -m g:groupOfProgrammers:--- "Folder 2.1"
# setfacl -m g:groupOfProgrammers:r-x "Folder 1"

The above gives the apache user (substitute with whatever user your apache/nginx/whatever is running as) read-only access to the target of the symlink, and gives groupOfProgrammers read access to the directory the symlink is in (so that groupOfProgrammers can get a complete directory listing there), but turns all permission bits off for the same target of the symlink.

  • Thank you Joel - I understood everything you wrote already, and then ran into the EDIT which was new.
    – Bradley
    Jun 9, 2013 at 1:41

We still don't know what you have done on the file system level. The usual approach would be to make root (or another admin account) the owner of all those directories and give the level 2 directories to the groups with whatever rights for the owner, rwx for the group and none for others. It may be useful to have the sticky bit set, too (chmod o+t "$dirname").

The level 1 directories should belong to admin user and group (e.g. root:root) with r-x rights for others.

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.