Al Viro 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). 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.
Well, chattr already has +s which means exactly this. It's just not respected by... anything. The 0/5 mentioned it, albeit briefly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
