Best workaround for file's symbolic link with different group than file

Question

Target situation:

• data/file.txt owned by myUser:myUser and "-rw-rw-rw-" (chmod 666)
• symbolic link /tmp/file.txt owned by postgres:postgres and "-rw-rw-rw-"

So, I can edit the file with my user, and the other user (postgres) can read and write it also, but the link and the file are owned by different users.

Real world situation: same step by step of this other question,

sudo rm /tmp/file.txt  # if exist, remove

cd ~
sudo chmod 666 data/file.txt
ls -l data/file.txt    # "-rw-rw-rw-" as expected
more data/file.txt     # working fine
sudo ln -sf $PWD/data/file.txt /tmp/file.txt  # fine
ls -l /tmp/file.txt    # "lrwxrwxrwx",  /tmp/file.txt -> /home/thisUser/file.txt
more /tmp/file.txt     # fine

sudo chown -h postgres:postgres /tmp/file.txt

sudo more /tmp/file.txt   #  NOT WORK! 

A workaround is sysctl -w fs.protected_symlinks=0 (then more /tmp/file.txt will work fine) but it is not secure; I need another solution.

---

See real-life problem here

Answer 1

The directories /home and /tmp aren't really appropriate for this, and neither is using a symbolic link. Make a directory to store the file and set up permissions for it using an ACL. Let's say that your username is peter. Some of the commands below might be superfluous, and these are given merely to be explicit.

# Make a new directory to store the `file.txt`.
#
sudo mkdir /var/my_dir

# Change ownership and group ownership to root.
#
sudo chown root:root /var/my_dir

# Only allow root and members of root to read the directory.
#
sudo chmod 0750 /var/my_dir

# Begin to augment standard permissions with ACLs.

# Below, allow peter rwx for all new file system objects in /var/my_dir.
# (-d means "default" and -m means "mask")
#
setfacl -d -m u:peter:rwx /var/my_dir

# Set the same mask for the directory itself.
#
setfacl -m u:peter:rwx /var/my_dir

# Below, allow postgres r-x for all new file system objects in /var/my_dir.
#
setfacl -d -m u:postgres:r-x /var/my_dir

# Set the same mask for the directory itself.
#
setfacl -m u:postgres:r-x /var/my_dir

Now, peter can create files in /var/my_dir, and postgres can read them.

It may also be convenient to link the directory in your home directory.

cd && ln -s /var/my_dir .

Files in /tmp should disappear on reboot. Generally speaking, or perhaps arguably, it would not be a good practice to link to files in your home directory. I could expound on that statement if you don't already understand. A better location for this purpose might be /usr/local/var/my_dir, but the main point is to try to get the permissions right instead of using /tmp and /home with symbolic links for this purpose.

Update

This might also be done in a standard, simpler way that would be more compatible with other software like SFTP/SCP clients.

sudo mkdir /var/my_dir
sudo chown peter:postgres /var/my_dir
sudo chmod 0750 /var/my_dir

Now, whatever files exist in /var/my_dir can only be read by root, peter and postgres, while only peter and root can write.

Then just make sure your umask creates files that postgres can read.

cd
touch test
ls -l test

If the result shows r for "others," then postgres will be able to read the file in /var/my_dir.

Yet another approach...

sudo touch /usr/local/var/file.txt
sudo chown peter:postgres /usr/local/var/file.txt
sudo chmod 0640 /usr/local/var/file.txt
cd
ln -s /usr/local/var/file.txt .

Above, we work with a single file, no directories. Again, all of these are simply setting permissions. You merely have to decide how you want to approach the situation, having more knowledge about what you are doing than what we can read in the question.

Answer 2

There is a misconception here. There is no point in changing the rights of a symbolic link. Quoting the chmod manpage (bolding is mine):

chmod never changes the permissions of symbolic links; the chmod system call cannot change their permissions. This is not a problem since the permissions of symbolic links are never used.

No need of symlinks. To share your file with PostgreSQL, you must change the group-owner of the file to the group of user postgres (that is postgres on Debian-like systems), then chmod g+rw your file.