Messages in this thread |  | | Date | Fri, 13 Dec 1996 17:58:03 +0200 (EET) | From | Johan Myréen <> | Subject | Re: Proposal: restrict link(2) |
| |
On 13 Dec 1996, Aaron M. Ucko wrote: > Dan Merillat <Dan@merillat.org> writes: > > > Would anything BREAK if we made link() depend on write access? And does > > POSIX require that ability? > > POSIX is not entirely clear. From the 1996 edition of the spec: > > } The implementation may require that the calling process has > } permission to access the existing file. > > I'm pretty sure "access" means "read access," but I suppose one could > construe it to mean "write access."
Considering the Unix file system semantics, I would definitely interpret the spec so that you need access to the file in the sense of the F_OK mode in the access() system call. From the access(2) man page:
F_OK requests checking whether merely testing for the existence of the file would be allowed (this depends on the permissions of the directories in the path to the file, as given in path- name.)
end quote
A Unix file system can be thought of as consisting of two layers: The first layer implements a collection of file objects that are unnamed and are not organized in any hierarchy with respect to each other. The file objects have attributes like size, permissions, access time and owner. The second layer implements the directory structure: a file is given a name in the tree structure by linking it to some directory. There can be an arbitrary number of links to a file anywhere in the directory structure. When the last link to a file is removed (and no process longer has the file open), the file object is freed.
These two layers are quite well separated. The ability to search a directory has got nothing to do with whether you can read from or write to a file. (On the other hand, the permissions on _directories_ determine whether you can access the files contained in the directories.)
Johan Myreen jem@iki.fi
|  |