How Do I Block Read Access to a Symbolic Link?

Question

I have this file structure:

> APPLICATION 1
>> CONTROLLER (@JuniorProgrammers)
>> MODELS (symlink to SHARED/MODELS)
>> VIEWS (@Designers)
> APPLICATION 2
>> CONTROLLER (@JuniorProgrammers)
>> MODELS (symlink to SHARED/MODELS)
>> VIEWS (@Designers)
> SHARED
>> 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.

Answer 1

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.

EDIT:

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.

Answer 2

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.