In linux it's possible to change the owner or the group owner of a symbolic link (symlink). I was wondering why someone would want to do that, since permissions of a symlink are not used when accessing a file through it.
I can only imagine one use case where it could be useful: to allow a user to delete a symlink in a directory with sticky bit.
Do you know other cases where it might be useful to change the owner or group owner of a symlink ?
Suppose root is working in a directory that Eve can write to. There's a file foo in this directory that needs to be changed to belong to Eve. So root types chown eve foo. But just before root hits Enter, Eve runs ln -sf /etc/passwd foo. Now /etc/passwd belongs to Eve! If root can run chown -h eve foo to make sure not to follow symlinks, then the most harm that can be done is that some other file in the same directory has been changed to belong to Eve.
lchown is also convenient when you're changing the owner of a directory tree. You don't need to worry about accidentally affecting a file outside the tree because you called chown on a symbolic link.
mv myfile foo, and root will end up changing the owner of myfile. But myfile has to be a file that Eve can create or move into that directory, it can't be any file on the system.
Commented
Mar 2, 2012 at 0:47
chown -h as a cautionary measure when changing ownership of a file that isn't supposed to be a symlink, but still might be (an edge case, IMO). It doesn't explain why one might wish to change the ownership of a file that is in fact intended to be a symlink, which is what the question asked.
chown change the owner of "a file outside the tree" is all you are changing is the directory's owner?
chown -R, that calls the (l)chown system call on each directory entry. If the directory entry is a symbolic link then you must not call the chown system call on it because that would affect the target of the link which may be located outside the tree.
Commented
Nov 18, 2016 at 10:31
Apache can be configured to follow symlinks only if the owner of the link matches the owner of the destination. This can help prevent users from creating links for web access to files they don't own (e.g. /etc/passwd).
... so let's say you, as root, wanted apache to follow a link to display a certain logfile, which was owned by xymon or something, but you didn't want to relax apache's security by allowing it to follow symlinks regardless of owner. Then you might want to make xymon the owner of the symlink.
/etc/passwd, then the badguy might have read access to that file without having any other local access -- but would be thwarted by the symlink being owned by apache.
Commented
Mar 13, 2012 at 15:35
The first answer doesn't seem to adress the question, and the second one only applies to Apache.
One thing I can think of for linux in general is that it's only possible for an ordinary user to make a hard link to a symbolic link if the user is the owner of the symbolic link. Why one would want to make such a link, I don't know.
Another thing is that an ordinary user can only change the group ownership of a file if the user owns the file (and is also a member of the group the file is being added to.) That brings up the question of what the group ownership of a symbolic link does. In an organization, it might be useful as a tag to indicate which team would have need of the link.
Also, on Ubuntu at least, anyone can update the timestamp of a symbolic link. However, there may be some systems that only allow the owner to. What good the timestamp does for a symbolic link, I'm not sure, but it may give some useful information on how much it's used.
Edit: I just realized another reason why ownership would be important. The link could be inside of a sticky directory, where only the owner of a file can delete or rename it.
If you want to have a link to a file on your opening screen, the symbolic link has to be in the
"/home/username/Desktop"
directory.
And, the symbolic link itself must have root:root (0:0) ownership, otherwise the link does not work.
(Ubuntu/Debian etc.)
I have an program that appends to a log file. These log files are created monthly each with a different name. Rather than have the software figure out the exact filename, I use a "generic" filename (say data.log) which is a symbolic link that points to the current file for that month. This is automated on a cron job.
Now as a new monthly file is created, it needs to point the symbolic link to the new file. If there is an ownership/group conflict, the software can't change the symbolic link. So you need ownership/group write privileges to change the symbolic link.
