Re: [PATCH 2/2] block: create ioctl to discard-or-zeroout a range of blocks

On Mon, Mar 14, 2016 at 10:46:03AM -0400, Theodore Ts'o wrote:

On Mon, Mar 14, 2016 at 06:34:00AM -0400, Ric Wheeler wrote:

quoted

I think that once we enter this mode, the local file system has effectively
ceded its role to prevent stale data exposure to the upper layer. In effect,
this ceases to become a normal file system for any enabled process if we
control this through fallocate() or for all processes if we do the brute
force mount option that would be file system wide.

Or we do this via group id, such that we are ceding responsibility for
proventing stale data exposure to the processes running under that
group id.  That process has the responsibility for making sure that it
doesn't return any data from that file unless it has been written, and
also to make sure the permissions of that file are not readable by
processes that aren't in that group.  (For example, owned by user
ceph, group ceph, with premissions 640).

Root can still change the group id of a file that has exposed stale
data and hence make it visible outside of the group based
containment wall. i.e. external actors can still unintentionally
expose stale data, even though the application might be correctly
contained and safe.

What we are missing is actual numbers that show that exposing stale
data is a /significant/ win for these applications that are
demanding it. And then we need evidence proving that the problem is
actually systemic and not just a hack around a bad implementation of
a feature...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com