> Chris Demetriou writes:
> >It's worth noting that link() could, in fact, have a variant that
> >takes a file descriptor for the 'source' file, and even a file
> >descriptor for the destination directory. [...]  However, I don't
> >think implementing that is either necessary or appropriate.
> 
> Since you didn't say explicitly:  This would also mean that you could
> get permanent access rights to inherited file descriptors.  Which
> could open security holes.

"iffy."

remember, right now you can link to files you don't have access to,
e.g. (if /tmp is really on /):
	"cd /tmp ; ln /sbin/init .'

Doing that doesn't create security holes.


The one potential 'hole' is the case where you're handed a descriptor
to:

	a/b

where 'b' is a world-readable file that's in directory 'a' which has
strict permissions set to protect 'b'.  In that case, you could link
'b' to someplace else, and have it readable by everybody.  However,
some would argue that that's a careless use of permissions, and also
that you could accomplish the same end via another (more complicated)
mechanism.  In general, if you're giving somebody file-descriptor
access to a file, that 'somebody' should be trusted.


Anyway, like i said: "I don't think implementing that is either
necessary or appropriate."




cgd