Date: Tue, 3 Feb 2015 23:33:32 +0000
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Alexander Holler <holler@ahsoftware.de>
Cc: "Theodore Ts'o" <tytso@mit.edu>, linux-fsdevel@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
Message-ID: <20150203233332.GE29656@ZenIV.linux.org.uk>
References: <1422896713-25367-1-git-send-email-holler@ahsoftware.de>
 <1422896713-25367-2-git-send-email-holler@ahsoftware.de>
 <20150203060542.GZ29656@ZenIV.linux.org.uk>
 <54D071AA.1030302@ahsoftware.de>
 <20150203075616.GA29656@ZenIV.linux.org.uk>
 <54D08BF4.3000903@ahsoftware.de>
 <54D093A0.7090201@ahsoftware.de>
 <54D0C3B8.2050507@ahsoftware.de>
 <20150203174839.GD2509@thunk.org>
 <54D10D0E.8090204@ahsoftware.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54D10D0E.8090204@ahsoftware.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2149
Lines: 41

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-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/