On Tuesday 04 August 2009 19:20:09 John Stoffel wrote: > >>>>> "Valdis" == Valdis Kletnieks <Valdis.Kletnieks@xxxxxx> 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 -- 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
