Re: Proposal: restrict link(2)

=?ISO-8859-1?Q?Johan_Myr=E9en?= (jem@vistacom.fi)
Fri, 13 Dec 1996 17:58:03 +0200 (EET)


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