lkml.org 
[lkml]   [2009]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: fanotify - overall design before I start sending patches
Date
On Tuesday 04 August 2009 19:20:09 John Stoffel wrote:
> >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@vt.edu> writes:
>
> Valdis> On Tue, 04 Aug 2009 12:27:48 EDT, Eric Paris said:
> >> On Tue, 2009-08-04 at 17:09 +0100, Tvrtko Ursulin wrote:
> >> > Would it make more sense to deny on timeouts and then evict? I am
> >> > thinking it would be more secure with no significant drawbacks. Also
> >> > for usages like HSM allowing it without data being in place might
> >> > present wrong content to the user.
> >>
> >> I'd be willing to go that route as long as noone else complains.
>
> Valdis> Yes, in my world, "deny on timeout and evict" is the better
> Valdis> design decision. For an HSM, you'd rather have a
> Valdis> quick-and-ugly death on a failed file open than an app
> Valdis> accidentally reading the HSM's stub data thinking it's the
> Valdis> original data.
>
> Speaking as somone who is working slowly to deploy an HSM service, one
> thing to note is that when you *do* see the stub file contents, you
> know that your HSM is busted somehow.
>
> How will fanotify deal with this issue? Sorry, I haven't paid enough
> attention to this thread though I know I should since it's up my $WORK
> alley.

Would it make sense to allow the listener to pass in (on registration, maybe
also on response) the error code which will be received by userspace? In that
way HSM could set it to -ENODATA (or something), malware scanning to -EACCESS
etc. which would give userspace a clearer indication of what went wrong.

Tvrtko


\
 
 \ /
  Last update: 2009-08-05 11:35    [W:0.067 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site