2

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?
2

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.

  • Wow! I now see it much clearer. However, is this a security hole? As it appears that bob wasn't meant to put executables inside the shared folder, but with the hardlink trick he can – andresgongora Jul 26 '18 at 13:20
  • Owner can change permissions anyways (bob can change the permissions of files he owns in the shared folder). Also, if bob can create files (with permissions of his liking) in directory it doesn't really make a difference if the file is a hard link or not. – sebasth Jul 26 '18 at 15:08
  • (Also, an user can create a hardlink to any file on same filesystem, which can be a problem if root re-assigns ownership of files in the new location. For example explained in Dan Walsh's blog. – sebasth Jul 26 '18 at 15:13
  • @sebath I've tried it but it's not the case. For any reason (maybe there is an additional policy on the server I'm not aware of), bob can't change the ownership of any file inside the shared folder. I'll try to inquiry the server admin to see whether this is because ACL or if there is something more going on. – andresgongora Jul 27 '18 at 6:20
  • bob shouldn't be able to change ownership, but any permissions on files he is owner of. – sebasth Jul 28 '18 at 9:14

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.