On Fri, 28 Sep 2001, Andrew Brown wrote:

# as for flink(2), no.  flink(2) would be a terribly bad idea.  consider
# that when opening a file, *all* the permissions on *all* the inodes in
# the path to the file are considered.  if you were able to get some
# process to hand you an open file descriptor to some file somewhere
# that relies on being protected by permissions in the path and you were
# able to flink(2) it to some arbitrary name, you could bypass the
# permissions set that had been established.

If you can get some process to hand you said open file descriptor,
assuming that said file descriptor pointed to a file that would meet
all the physical conditions of a link() call (exclusive only of path
navigation), what's to keep you from doing

	lseek(fd, (off_t) 0, SEEK_SET);
	while((len = read(fd, (char *) buf, buffer_size)) > 0) {
		write(outfd, (char *) buf, len);
	}

in the first place?

If you had an flink(fd, path, mode), it would have to go through normal
semantics, i.e. no creation of directories on the fly (that's not the
job of a syscall), make sure you can create said path as an end node,
make sure said end node lives on the same device (making a symlink to
a nonexistent file would be awfully silly, wouldn't it?)

I've often wished for an flink() call, as well as an funlink() call.
Now BEFORE you jump on me for the last one, I do realise its folly, because
it would effectively do a 'clri' on the inode pointed to by the fd in
question -- unlink() should be restricted to pathnames and not operate
on file descriptors EVER.  A user-accessible clri routine is the last
thing we want floating around.

A user-accessible way to link in an fd to an anonymous place, however, does
not strike me as all that odd of an idea.

Take into account the requirements of a link() call; if you've got the
fd, you've got access to the data of the file as it is.  Chances are rather
good that if it's protected by directory accesses and such, those directories
will live on a filesystem that does not have publicly writable space in which
to store a hard link to said file.  And since cross-device hard links are
prohibited, and given the properties of symbolic links to be useless in
a case like this, I don't see that we're losing, here.

Of course, we'd have to prove that it is not inherently insecure to
permit this and then get everyone else to pick up the system call.

				--*greywolf;
--
NetBSD, Net Profit.