lkml.org 
[lkml]   [2010]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT PULL] notification tree: directory events
From
Date
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







\
 
 \ /
  Last update: 2010-08-20 22:41    [W:0.126 / U:0.812 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site