On Sat, Mar 12, 2016 at 09:30:47AM +1100, Dave Chinner wrote: > It's all well and good to restrict access to the fallocate() call to > limit who can expose stale data, but it doesn't remove the fact it > is easy for stale data to unintentionally escape the privileged > group once it has been exposed because there is no record of the > fact the file contains uninitialised blocks.... Ultimately, it's up to the trusted process to make sure it never reveals any stale data. For example, if you have the policy that all data is encrypted at rest, and the trusted process is always going to be decrypting any blocks it reads from disk before passing it on its client (for example) then any stale data is going to be obscured by the decryption step before it gets passed on. At the end of the day it's about whether you trust the userspace program or not. I know there's a long and venerated traition of assuming that all application programmers are incompetent, but that leads to file systems doing more work than what is strictly necessary, and that has a performance tax. And if the result is the cluster file system authors decide to create a user space file system, and bypass the kernel file system directly, then we have to trust them to do a competent job anyway. But if you believe that there are still ways in which a in-kernel file system can add value, then it's encumbent on us to to be a bit more flexible and not assume that all userspace programmers are blithering idiots. Cheers, - Ted -- 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
