> Clayton Weaver wrote:
> > If the client process subsequently flink()s to the inode, it is merely
> > a zerocopy file copy.
> As far as access to the data is concerned, yes. But there's also the
> location of the file. E.g. this might enable you to fill somebody
> else's quota, or, if distinct physical devices can be be covered by
> the same file system, to access a physical device that would
> otherwise not be available to you.
> Example: I write some kind of RAID mounted at /world, that contains
> my disk under /world/disk, and some Flash storage under /world/flash.
> I protect /world/flash against writes by other people. If a
> read-only FD could be turned into something writeable, some malicious
> creature could "wear out" my Flash by writing to it a lot of times.
> - Werner
I'm wondering about the semantics of the unlink
of the last directory entry and subsequent
flink(). When is the inode updated?
I presume that the open fd has owner and mode
information from open(), but would flink()update the inode with new owner information if the
last directory reference had already been
unlinked, and how would this interact with
owner information associated with the open fd
for subsequent file operations? Would fchmod() then succeed, even if the new process is not
owned by the original owner of the flink()ed
to inode? Are any changes to the inode data
delayed until after close()?
What about multiple flink()s before an inode
update has appeared in the filesystem?
It seems to me that "change of owner of the inode" via flink() is an issue, and application programmers that unlink the last directory reference and then pass the open fd to another process had better have no sentimental attachment to the existing access constraints on the file. flink(), close(), open() isn't exactly a difficult hoop to jump through, even if you've passed an
open fd for a read-only file (that you unlinked
any directory references to).
Regards,
Clayton Weaver
<mailto: cgweav@email.com>
-- _______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/