On Tue, Mar 15, 2016 at 01:43:01PM -0700, Linus Torvalds wrote: > Put another way: this is not about theoretical leaks - because those > are totally irrelevant (in theory, the original discard writer had > access to all that stale data anyway). This is about making it a > practical interface that doesn't have serious hidden gotchas. So there have been two interfaces proposed so far: 1) A mount option which specifies the group id under which a program must be running in order to have the permission to use FALLOC_FL_NO_HIDE_STALE flag in the fallocate system call. 2) The program must have read access to the underlying block device inode under which the file system is mounted in order to have the permission to use the FALLOC_FL_NO_HIDE_STALE flag in the fallocate system call. In both cases, the application has to be make C source code changes to use this feature, and the system administrator has to set up the application so it has the privileges to use it. In the case of #1, the sysadmin has to specify a mount option as well. We're doing #1 in production in a very large number of mounted disks today. Linus has suggested #2, although there was some concern that screw-up in the user namespaces configuration could result in accidentally in a security exposure. (To which my response is, as opposed to the gazillions of other security nightmares which the user namespace makes us vulnerable to?) Still, my preference is for #1, since the mount option acts as an additional control for those really paranoid types that seem convinced that it can't be used safely, and it's what we're doing in production already. I'm open to #2 if other people are OK with it, though. 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
