Tightening security: not for the impatient
Posted Jul 3, 2012 22:01 UTC (Tue) by ScottMinster
Parent article: Tightening security: not for the impatient
a hard link to a file can only be created if the user owns the file or has write access to it
This doesn't sound too good. Where I work, we have applications that regularly create hard links to files just for reading. The reason we do this is in case the file is replaced by a new version while it is being read. This shouldn't be a problem on most file systems, but NFS has given us trouble in the past, and we're often using NFS filesystems.
The code follows the pattern of link(), open(), and unlink(). The NFS server will keep the unlink'ed file, and more importantly the NFS key (or whatever its called) around so the original file's contents can be read, even if the file is replaced with a new version (through writing to a temporary file and renaming).
While the code is robust enough to fallback on opening the original file instead of a temporary link if it cannot make the link (often happens if the directory itself is not writable), it would be annoying to lose this feature. We've had weird race conditions in the past on NFS without this logic.
Perhaps link() should be allowed to work if the user has read or write access to the file? Making a hard link to a file that cannot be read by the current user does seem to have little purpose.
to post comments)