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: > > 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@xxxxxxxxxxxxx -- 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
