Messages in this thread | ![/](/images/icornerl.gif) | | From | "Clayton Weaver" <> | Date | Wed, 09 Apr 2003 19:31:16 -0500 | Subject | Re: [PATCH] new syscall: flink |
| |
----- Original Message ----- From: Werner Almesberger <wa@almesberger.net> Date: Mon, 7 Apr 2003 15:43:03 -0300 To: Clayton Weaver <cgweav@email.com> Subject: Re: [PATCH] new syscall: flink
> 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/
| ![\](/images/icornerr.gif) |