Re: ecryptfs and fanotify

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 14/08/12 21:27, Tyler C Hicks wrote:


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 think that matters, either:

a) The file is already open, in which case the fanotify request will
simply pass on the already opened lower file. Or
b) The file is not open, and the flag will be passed onto the new lower
file open request.

For HSM: The lower file will be restored when the first open happens,
which is as required. Presumably the file won't be closed until the last
upper file descriptor is closed, so the HSM won't archive the file too
early either.

For fatrace: The initial open is recorded, and then writes? (I haven't
looked at fatrace in detail).

For AV: The lower file can't be scanned anyway, so it doesn't matter as
long as it doesn't lock up the system.

--
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.
--
To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Crypto]     [Device Mapper Crypto]     [LARTC]     [Bugtraq]     [Yosemite Forum]

  Powered by Linux