On Friday 20 August 2010 11:21:27 Christoph Hellwig wrote: > On Thu, Aug 19, 2010 at 11:19:07PM -0600, Andreas Dilger wrote: > > What about unifying the file identification here with the file handle > > used for open_by_handle()? That keeps a consistent identifier for the > > inode between multiple system calls (always a good thing), and allows > > the inode to be opened again via open_by_handle() if needed. > > That's what the dmapi callouts that are intendeded to do just about the > same as fanotify always did. I'm pretty sure I brought this up earlier > in the discussion. I remember you bringing this up. The persistent handles require CAP_DAC_READ_SEARCH for using open_by_handle() to prevent an unprivileged process from forging handles and bypassing directory permission checks. This would be okay for users of fanotify which can listen to all events in their namespace (and which requires CAP_SYS_ADMIN anyway). I don't see how open_by_handle() could be made safe to use by arbitrary processes; I don't think we can make the handles cryptographically strong, for example. But I may be overlooking something here. [Side note: checking for CAP_DAC_READ_SEARCH in fanotify would probably be enough when no perm events are involved because dentry_open() performs tail permission checks anyway.] In the future it will make sense to extend fanotify to allow unprivileged processes to listen to "their own" events, for example, like inotify does today. (You know that providing a better inotify replacement was one of the goals of fanotify before it got merged anyway.) Unprivileged processes wouldn't be allowed to use open_by_handle() anymore though, and so file handles still look like a better choice for fanotify to me. Thanks, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
