How do hard links, symbolic links, and ACL folder permissions interact?

Question

This one was a bit tricky for me to realize, but I came across a very weird behavior involving ACL extended file permissions and hard/symbolic links. I'll do my best to keep my question short and to the point, but I first have to show you an example of my current situation, as I don't know whats happening or what it is called.

---

Suppose we have a system with two users, let's call them alice and bob, who to a certain degree share a folder called stuff with the following permissions:

bob@server:~$ getfacl /home/stuff getfacl: 
Removing leading '/' from absolute path names
# file: home/stuff
# owner: alice
# group: bob 
user::rwx
group::-wx
other::---
default:user::rwx
default:user:bob:rwx
default:group::-wx
default:mask::rwx
default:other::---

As you see, the owner of the folder is alice, but bob can write stuff in there and make it executable, so that alice could run in (+x flag). However, because of ACL, everytime bob writes/copies a file into stuff, the permissions of the file get altered and end up being as follows. Assume we create a file in bob's home dir and move it to stuff.

bob@server:~$ touch myfile
bob@server:~$ chmod 777 myfile
bob@server:~$ ls -la myfile
-rwxrwxrwx 1 bob bob 0 myfile

bob@server:~$ mv myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
-rwxrwx---+ 1 bob bob 0 /home/stuff/myfile

As you can see, even though myfile is in the folder stuff, alice would have no access to it. Because the file belongs to bob:bob, alice would have to access it with the "others" file permissions, which are --- as per the last of the above ls commands. Still, because alice is the owner of the folder, she can delete them (although I get a warning about myfile being protected).

Now comes the fun part. If instead of moving/copying the myfile, I create a hard link to it, watch what happens.

bob@server:~$ ln myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
-rwxrwxrwx 2 bob bob 0 /home/stuff/myfile

Apparently alice can read and use it. In fact, if tested it on my system and she can indeed. Notwithstanding, a symbolic link seems not to work at all.

bob@server:~$ ln -s myfile /home/stuff/myfile
bob@server:~$ ls -la /home/stuff/myfile
lrwxrwxrwx 1 bob bob 4 /home/stuff/myfile -> /home/bob/myfile

This time, although the link also has all permissions set to lrwxrwxrwx (precisely because its a link and anyone has to be able to follow it to get the permissions) alice can not execute it, only delete it.

---

My questions:

• Why can I "skip" the ACS permissions with a hard link in the first place?
• And why does this same trick not work with symbolic links?
• Is this intentional, or is it a security hole?

Answer 1

As alice has write permission to stuff/ directory, alice can modify its contents even if she isn't the owner of the files.

When using Linux ACLs, when file is created (or copied, as copy creates new file at target) permissions are applied as described by man acl. Moving a file with mv preserves permissions when the file can be moved without copying. Looks like for some reason mv can not move the file and does a copy instead, since ACLs are applied to myfile.

Creating a hard link is quite different. Creating a hard link creates a directory entry (at the target directory), which points to the same inode as the original file, in other words, the same file exists in more than one directory. File permissions, both ACLs and traditional UNIX permissions, are stored in the inode. As both /home/stuff/myfile and /home/bob/myfile point to the same inode, any change in either will reflect to the other. This is why alice can access the hard link. The permissions of /home/bob/myfile (777) are the same as the permissions of /home/stuff/myfile.

Symbolic links instead points to the target path. Accessing the file that the symbolic link is pointing to requires the same permissions as accessing the target file. Possibly alice doesn't have search (execute bit) access to bob's home directory, and therefore access fails.