Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
From: Andreas Dilger <adilger@dilger.ca>
In-Reply-To: <20150203233332.GE29656@ZenIV.linux.org.uk>
Date: Tue, 3 Feb 2015 21:16:18 -0700
Cc: Alexander Holler <holler@ahsoftware.de>, "Theodore Ts'o" <tytso@mit.edu>,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Transfer-Encoding: 7bit
Message-Id: <64ABA02D-81FD-4724-BC04-71D39A7D1D22@dilger.ca>
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> <20150203233332.GE29656@ZenIV.linux.org.uk>
To: Al Viro <viro@ZenIV.linux.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2502
Lines: 56

On Feb 3, 2015, at 4:33 PM, Al Viro <viro@ZenIV.linux.org.uk> 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-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/