On Tue, Feb 03, 2015 at 07:01:50PM +0100, Alexander Holler wrote: > Yeah, as I've already admitted in the bug, I never should have use > the word secure, because everyone nowadays seems to end up in panic > when reading that word. > > So, if I would be able to use sed on my mails, I would replace > unlinkat_s() with unlinkat_w() (for wipe) or would say that _s does > stand for 'shred' in the means of shred(1). TBH, I suspect that the saner API would be something like EXT2_IOC_[SG[ETFLAGS, allowing to set and query that along with other flags (append-only, etc.). Forget about unlink; first of all, whatever API you use should only _mark_ the inode as "zero freed blocks" (or trim, for that matter). You can't force freeing of an inode, so either you make sure that subsequent freeing of inode, whenever it happens, will do that work, or your API is hopelessly racy. Moreover, when link has been removed it's too late to report that fs has no way to e.g. trim those blocks, so you really want to have it done _before_ the actual link removal. And if the file contents is that sensitive, you'd better extend the same protection to all operations that free its blocks, including truncate(), fallocate() hole-punching, whatever. What's more, if you divorce that from link removal, you probably don't want it as in-core-only flag - have it stored in inode, if fs supports that. Alternatively, you might want to represent it as xattr - as much as I hate those, it might turn out to be the best fit in this case, if we end up with several variants for freed blocks disposal. Not sure... But whichever way we represent that state, IMO a) operation should be similar to chmod/chattr/setfattr - modifying inode metadata. b) it should affect _all_ operations freeing blocks of that file from that point on c) it should be able to fail, telling you that you can't do that for this backing store. -- 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
