On 2012-08-14 17:01:14, Douglas Leeder wrote:
> On 14/08/12 11:50, Douglas Leeder wrote:
> >On 14/08/12 10:31, Florian Westphal wrote:
> >>Douglas Leeder <douglas.leeder@xxxxxxxxxx> wrote:
> >>>So as, I sent later, making fanotify only return one file event per
> >>>fanotify read(), So that suggests that the request is getting stuck
> >>>in a cycle or adding a request.
> >>>
> >>>Florian has also been looking at this problem, and has pointed out
> >>>that FMODE_NONOTIFY should prevent the loop seen in the backtrace, so
> >>>I'm wondering if it's getting lost somewhere in ecryptfs. Or perhaps
> >>>it needs to be explicitly propagated to the open request for the
> >>>lower file?
> >>
> >>Douglas, can you reproduce the problem with this patch applied?
> >>
> >>diff --git a/fs/ecryptfs/kthread.c b/fs/ecryptfs/kthread.c
> >>index 809e67d..1d8a53b 100644
> >>--- a/fs/ecryptfs/kthread.c
> >>+++ b/fs/ecryptfs/kthread.c
> >>@@ -74,7 +74,7 @@ static int ecryptfs_threadfn(void *ignored)
> >> kthread_ctl_list);
> >> list_del(&req->kthread_ctl_list);
> >> *req->lower_file = dentry_open(&req->path,
> >>- (O_RDWR | O_LARGEFILE), current_cred());
> >>+ (O_RDWR | O_LARGEFILE | FMODE_NONOTIFY),
> >>current_cred());
> >> complete(&req->done);
> >> }
> >> mutex_unlock(&ecryptfs_kthread_ctl.mux);
> >>@@ -133,7 +133,7 @@ int ecryptfs_privileged_open(struct file
> >>**lower_file,
> >> const struct cred *cred)
> >> {
> >> struct ecryptfs_open_req req;
> >>- int flags = O_LARGEFILE;
> >>+ int flags = O_LARGEFILE|FMODE_NONOTIFY;
> >> int rc = 0;
> >>
> >> init_completion(&req.done);
> >>
> >
> >That patch also seems to fix the problem - at least for AV scanning:
> >1) The encrypted files don't show up in the user-space test program.
> >2) Using the FanotifyMultiThreadScanner (old) from the git tree doesn't
> >lock up. (With the single event read() patch removed for the moment).
> >
> >
> >However I don't think this is a sufficient solution for general fanotify.
> >For example an HSM may need to get the fanotify event to restore the
> >encrypted file to disk.
> >Or a file-access recorder (e.g. http://www.piware.de/tag/fanotify/ )
> >will want all the accesses, including those 'generated' by the
> >fanotify_read() call itself.
> >
> >Talpa, in this case, has it easier, since it is only used for AV, it can
> >ignore any accesses that it's caused.
> >
> >What we might be able to do is set FMODE_NONOTIFY for the lower access
> >if the upper access had it set? Since HSM and fatrace don't want to
> >access the contents when they intercept.
> >
> >I guess HSM and fatrace might not intercept ecryptfs mounts anyway,
> >since they don't directly access the disk?
> >
>
> So I've looked at the path required for that and I guess it involves
> passing file->f_flags from ecryptfs_open through:
> * ecryptfs_get_lower_file (main.c)
> * ecryptfs_init_lower_file (main.c)
> * ecryptfs_privileged_open (kthread.c)
>
> Does that look like the correct to you, Tyler?
Yeah, that should be the full list.
However, I don't think this approach will work with the current
eCryptfs design. eCryptfs only keeps one lower file open per inode. That
means that there could be 10 file descriptors opened for a given
eCryptfs file but there is still only one lower file opened that
everything is multiplexed through.
I don't like the design, but it has been that way for years and I
haven't touched it. For your approach to work, I think eCryptfs would
need to be changed to have a 1-to-1 mapping of upper files to lower
files.
Tyler
>
> I think HSM and fatrace usages won't request the file be opened, so
> won't trigger that path though fanotify.
>
> --
> Douglas Leeder, Senior Software Engineer
>
> ________________________________
>
> Sophos Limited, The Pentagon, Abingdon Science Park, Abingdon, OX14 3YP, United Kingdom.
> Company Reg No 2096520. VAT Reg No GB 991 2418 08.
Attachment:
signature.asc
Description: Digital signature
