On Fri, Mar 11, 2016 at 10:25:30AM -0800, Linus Torvalds wrote: > On Fri, Mar 11, 2016 at 9:30 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > > > What if we had an ioctl to do these data-leaking operations that took, > > as an extra parameter, an fd to the block device node. They allow > > access if the fd points to the right inode and has FMODE_READ (and LSM > > checks say it's okay). Sure, it's awkward, but it's much safer. > > That sounds absolutely horrible. > > I'd *much* prefer the suggestion from Alan to simply have a mount-time > option to enable it. That way, you will never get any surprises, and > no "subtle new behavior for somebody who set their system up in a way > that doesn't allow for this". > > So you'd have to explicitly say "my setup is ok with hole punching". Except it's not hole punching that is the problem. Hoel punching makes sure that the underlying blocksare removed and so whatever data is in them cannot be accessed any more. The problem here is preallocation of unwritten blocks that expose the stale data if the filesystem skips marking those blocks as unwritten. And, so, what happens when a file that is preallocated with the unwritten bit so it exposes stale data then has it's owner/group changed? Or copied by root/user in privileged group to a different location that other users can access? Or any of the other vectors that can result in the stale data being copied/made available to unprivileged users? 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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
