From: Alexander Holler <holler@ahsoftware.de>
To: Al Viro <viro@ZenIV.linux.org.uk>
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)
Date: Wed, 04 Feb 2015 11:19:01 +0100 [thread overview]
Message-ID: <54D1F215.9030404@ahsoftware.de> (raw)
In-Reply-To: <20150203233332.GE29656@ZenIV.linux.org.uk>
Am 04.02.2015 um 00:33 schrieb Al Viro:
> 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.
My intention to use unlinkat() or unlinkat_s() was the following:
- It can be supported by most filesystems (see my fat patch)
- It doesn't really make any promises it can't, like deleting leftovers
of an already modified file. That's where a much more complicated
solution like the 's' attribute would appropriate. It just should try to
wipe the current contents of a file.
The second reason was also the reason why I've crafted the subject of
the RFC very carefully: "Offer a way for userspace to request real
deletion of files".
I did that to avoid the nitpickers. It doesn't say how the request is or
has to be handled. I was aware of all the problems which arise if one
tries to fullfill what the 's' flag promises. The final result of trying
to get a 100 percent solution is just what we have now: nothing at all.
It wasn't the first time I've posted a patch to LKML, I know that
maintainers like to request high towers from ordinary people and
therefor very often nice dog houses were refused. There might be a
legitimate reason to request a high tower from a big company, but that's
something totally different.
And I refuse to try to understand why maintainers request high towers. ;)
And because hope never dies, I was again silly enough to post a simple
patch. ;)
Regards,
Alexander Hpller
next prev parent reply other threads:[~2015-02-04 10:19 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 17:05 [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files Alexander Holler
2015-02-02 17:05 ` [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only) Alexander Holler
2015-02-03 6:05 ` Al Viro
2015-02-03 6:58 ` Alexander Holler
2015-02-03 7:56 ` Al Viro
2015-02-03 8:01 ` Alexander Holler
2015-02-03 8:10 ` Al Viro
2015-02-03 8:17 ` Alexander Holler
2015-02-03 8:51 ` Alexander Holler
2015-02-03 9:23 ` Alexander Holler
2015-02-03 12:48 ` Alexander Holler
2015-02-03 12:54 ` Alexander Holler
2015-02-03 17:48 ` Theodore Ts'o
2015-02-03 18:01 ` Alexander Holler
2015-02-03 23:33 ` Al Viro
2015-02-04 0:18 ` Alex Elsayed
2015-02-04 4:16 ` Andreas Dilger
2015-02-04 10:19 ` Alexander Holler [this message]
2015-02-04 12:07 ` Lukáš Czerner
2015-02-04 12:22 ` Alexander Holler
2015-02-04 12:42 ` Alexander Holler
2015-02-04 12:50 ` Alexander Holler
2015-02-04 13:07 ` Alexander Holler
2015-02-04 13:06 ` Michael Kerrisk
2015-02-04 13:21 ` Alexander Holler
2015-02-04 13:29 ` Alexander Holler
2015-02-04 14:19 ` Alexander Holler
2015-02-04 15:00 ` Austin S Hemmelgarn
2015-02-04 14:52 ` Lukáš Czerner
2015-02-04 16:12 ` Alexander Holler
2015-02-04 16:25 ` Lukáš Czerner
2015-02-04 16:45 ` Alexander Holler
2015-02-04 16:53 ` Alexander Holler
2015-02-04 19:33 ` Theodore Ts'o
2015-02-04 19:56 ` Alexander Holler
2015-02-03 7:58 ` Davidlohr Bueso
2015-02-03 7:52 ` Alexander Holler
2015-02-04 8:01 ` Michael Kerrisk
2015-02-02 17:05 ` [PATCH 2/5] WIP: fs: fat: support unlinkat_s() for secure deletion of files Alexander Holler
2015-02-02 17:05 ` [PATCH 3/5] WIP: fs: ext4: " Alexander Holler
2015-02-03 13:50 ` Lukáš Czerner
2015-02-03 14:50 ` Alexander Holler
2015-02-03 15:13 ` Alexander Holler
2015-02-03 15:24 ` Alexander Holler
2015-02-03 15:41 ` Lukáš Czerner
2015-02-03 15:46 ` Alexander Holler
2015-02-03 16:38 ` Alexander Holler
2015-02-03 18:50 ` Alexander Holler
2015-02-02 17:05 ` [PATCH 4/5] WIP: Add patch for coreutils to support unlinkat_s (x86_64 only) Alexander Holler
2015-02-02 17:05 ` [PATCH 5/5] WIP: Add test for unlinkat_s Alexander Holler
2015-02-03 15:15 ` [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files One Thousand Gnomes
2015-02-03 15:45 ` Alexander Holler
2015-02-04 8:01 ` Michael Kerrisk
2015-02-06 12:17 ` Alexander Holler
2015-02-07 5:56 ` Russ Dill
2015-03-02 10:03 ` Alexander Holler
2015-03-03 10:36 ` Alexander Holler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54D1F215.9030404@ahsoftware.de \
--to=holler@ahsoftware.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).