On 2010-08-20, at 09:29, Andreas Gruenbacher wrote: > 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 intended 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. If the file handles only need to have a limited lifetime for unprivileged processes, then they can contain a random salt that is kept on the in-core inode. For me and my intended HPC use case this would be a useful addition for open_by_handle() to allow unprivileged process access. At worst, if the inode is evicted from memory the process would redo the name_to_handle(), or do the slower open-by-path(). I suspect it would also be possible to have an array of per-superblock (or global) crypto keys that are hashed with the file handle data. That avoids the per-inode memory, and allows a well-defined lifetime for the handle (minutes, hours, days) only as a function of how quickly the crypto key needs to rotate (based on key length and attack speed) and the size of the array that is kept. > 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. Cheers, 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
