On Feb 3, 2015, at 4:33 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote: > 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). This already exists for a long time. "chattr +s file [file...]" marks inodes for "secure deletion" (EXT2_SECRM_FL), but this wasn't implemented. Cheers, Andreas > 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. Cheers, Andreas -- 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
