Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

Re: [PATCH 0/5] RFC: Offer a way for userspace to request real deletion of files

[Michael Kerrisk]

[CC += linux-api@]

Hello Alexander,

The kernel source file Documentation/SubmitChecklist notes that all
Linux kernel patches that change userspace interfaces should be CCed
to linux-api-u79uwXL29TaiAVqoAR/hOA@public.gmane.org See also
https://www.kernel.org/doc/man-pages/linux-api-ml.html. Please CC
linux-api@ on future iterations of this patch.

Thanks,

Michael


On Mon, Feb 2, 2015 at 6:05 PM, Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> wrote:
>
> Hello,
>
> some people already might have noticed that I've got a bit angry that
> no filesystem nor the posix api nor the linux syscalls are offering
> the userspace a way to request real deletion of one or more files (there's
> the 's' bit, see man chattr, but it is ignored by all FS which know it).
>
> Almost all filesystems are working such, that deleting a file just
> means it doesn't appear in the list of files anymore but the contents
> of the file still might be readable on the storage.
>
> So in the last 30 years many tools were created trying to circumvent that
> inability of all filesystems. Up to encrypting the whole storage which
> seems to be the current state of art and which many people recently tried
> to recommend to me.
>
> Also I'm using that workaround already myself since many years, I still
> believe it's a very bad, complictated, cumbersome and very uncomfortable
> way to make sure contents of files are not readable anymore. Besides that,
> just relying on encryption might hit back badly, because encryption often
> suffers from bugs in the implementation, bugs or even backdoors in the
> design and Moore. That means it's unsure how long the used encryption
> will defeat any tries to read the contents of a deleted file from storage
> and the used encryption might be worthless tomorrow. Not to speak about
> the problems with the necessary key-handling.
>
> What's the answer? Easy and obvious, just (try to) overwrite the contents
> of a file by request from userspace. Filesystems do know where on the
> storage they have written the contents to, so why not just let them delete
> that stuff themself instead? It's almost unbelievable that this was not
> already done in the past 30 years.
>
> So, now, after I've got angry enough, I've tried to do it myself, it seems
> to work and wasn't really hard.
>
> Of course, the easy way I think I've found isn't really my achievement.
> Instead it relies on all the work people have already done to support the
> trim command of SSDs. So thanks to all of them. You've made the following
> simple patches possible.
>
> How does it work:
>
> - Implement a new syscall named unlinkat_s() with the same signature as
> unlinkat(). With this syscall filesystems should make the old contents
> of files unreadable and should fail if they can't. This doesn't really
> have to be reliable, because it is often impossible for a filesystem to
> make enough assumptions about the underlying storage to promise secure
> deletion. But it has to mean that the filesystem tried everything it can
> to make sure the contents are unreadabler afterwards, e.g. by overwriting
> them, using secure trim or even just using trim. I've no idea if trim
> might be enough, if I would have implemented trim, it would clear the
> trimmed blocks in flash too, making them unreadable. But I haven't done
> such and I haven't tested if that's the case.
> The new syscall isn't meant to replace unlinkat() for everyday operations,
> therefor operation speed is ignored (see below in regard to a side effect).
>
> - Instruct the filesystem that it should discard or overwrite (all) freed
> blocks while the unlinkat_s() is at work.
>
> - Kill the inode while letting the filesystem discard freed blocks or
> overwrite them. As said before, this was easy through all the work already
> done by others. There even already existed a sb_issue_zeroout() which could
> be used instead of sb_issue_discard().
>
> - Sync the filesystem, to make sure the stuff is written to the storage.
>
>
> This approach has the side effect that while a call of unlinkat_s() is at
> work, all freed blocks will be destroyed, even those which aren't beloning
> to the unlink operation but are freed by possible other running actions.
> But in my humble opinion, that's nothing to care about and it keeps the
> implementation of this feature simple. I like KISS and that's imho the
> main feature of these patches.
>
>
> Things to be aware of when reading and starting to critisize my patches:
>
> - I've never had a look before at the kernel sources in fs/*.
> - They are the result of around half a dozen hours.
> - I'm aware that these patches are imperfect. Perfectionism does cost time
> for which I often don't feel the need to spend it unpaid.
> - I don't care for comments regarding style.
> - They are a proof of concept and are an offer. They are meant for other
> users, not maintainers. I wasn't paid for doing them and I don't care much
> if they will end up in the kernel. I already have and can use them, I'm
> happy with them and I don't really need them in the official kernel as I'm
> able to easily rebase them myself (thanks to git).
> - Don't be disappointed because the patches are that simple. The idea
> counts. ;)
>
>
> Regards,
>
> Alexander Holler
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Michael Kerrisk]

[CC += linux-api@]

On Mon, Feb 2, 2015 at 6:05 PM, Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org> wrote:
> Signed-off-by: Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
> ---
>  arch/x86/syscalls/syscall_32.tbl      |  1 +
>  arch/x86/syscalls/syscall_64.tbl      |  1 +
>  fs/namei.c                            | 38 ++++++++++++++++++++++++++++++-----
>  include/asm-generic/audit_dir_write.h |  1 +
>  include/linux/fs.h                    |  1 +
>  include/linux/syscalls.h              |  1 +
>  include/uapi/asm-generic/unistd.h     |  4 +++-
>  tools/perf/builtin-trace.c            |  2 ++
>  8 files changed, 43 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
> index 9fe1b5d..7a3d530 100644
> --- a/arch/x86/syscalls/syscall_32.tbl
> +++ b/arch/x86/syscalls/syscall_32.tbl
> @@ -364,3 +364,4 @@
>  355    i386    getrandom               sys_getrandom
>  356    i386    memfd_create            sys_memfd_create
>  357    i386    bpf                     sys_bpf
> +359    i386    unlinkat_s              sys_unlinkat_s
> diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
> index 281150b..97eaf01 100644
> --- a/arch/x86/syscalls/syscall_64.tbl
> +++ b/arch/x86/syscalls/syscall_64.tbl
> @@ -328,6 +328,7 @@
>  319    common  memfd_create            sys_memfd_create
>  320    common  kexec_file_load         sys_kexec_file_load
>  321    common  bpf                     sys_bpf
> +322    common  unlinkat_s              sys_unlinkat_s
>
>  #
>  # x32-specific system call numbers start at 512 to avoid cache impact
> diff --git a/fs/namei.c b/fs/namei.c
> index db5fe86..1ad3724 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -3717,7 +3717,7 @@ EXPORT_SYMBOL(vfs_unlink);
>   * writeout happening, and we don't want to prevent access to the directory
>   * while waiting on the I/O.
>   */
> -static long do_unlinkat(int dfd, const char __user *pathname)
> +static long do_unlinkat(int dfd, const char __user *pathname, bool secure)
>  {
>         int error;
>         struct filename *name;
> @@ -3759,8 +3759,25 @@ exit2:
>                 dput(dentry);
>         }
>         mutex_unlock(&nd.path.dentry->d_inode->i_mutex);
> -       if (inode)
> -               iput(inode);    /* truncate the inode here */
> +       if (inode) {
> +               // TODO:
> +               // if (inode is file and 's' flag is set)
> +               //      secure = true;
> +               if (!secure)
> +                       iput(inode);    /* truncate the inode here */
> +               else {
> +                       struct super_block *sb = inode->i_sb;
> +                       if (sb->s_op->set_secure_delete)
> +                               sb->s_op->set_secure_delete(sb, true);
> +                       // TODO: We should fail if secure isn't supported,
> +                       // look up how that's possible here.
> +                       iput(inode);    /* truncate the inode here */
> +                       // TODO: check if sb is still valid after the inode is gone
> +                       sync_filesystem(sb);
> +                       if (sb->s_op->set_secure_delete)
> +                               sb->s_op->set_secure_delete(sb, false);
> +               }
> +       }
>         inode = NULL;
>         if (delegated_inode) {
>                 error = break_deleg_wait(&delegated_inode);
> @@ -3796,12 +3813,23 @@ SYSCALL_DEFINE3(unlinkat, int, dfd, const char __user *, pathname, int, flag)
>         if (flag & AT_REMOVEDIR)
>                 return do_rmdir(dfd, pathname);
>
> -       return do_unlinkat(dfd, pathname);
> +       return do_unlinkat(dfd, pathname, false);
>  }
>
>  SYSCALL_DEFINE1(unlink, const char __user *, pathname)
>  {
> -       return do_unlinkat(AT_FDCWD, pathname);
> +       return do_unlinkat(AT_FDCWD, pathname, false);
> +}
> +
> +SYSCALL_DEFINE3(unlinkat_s, int, dfd, const char __user *, pathname, int, flag)
> +{
> +       if ((flag & ~AT_REMOVEDIR) != 0)
> +               return -EINVAL;
> +
> +       if (flag & AT_REMOVEDIR)
> +               return do_rmdir(dfd, pathname);
> +
> +       return do_unlinkat(dfd, pathname, true);
>  }
>
>  int vfs_symlink(struct inode *dir, struct dentry *dentry, const char *oldname)
> diff --git a/include/asm-generic/audit_dir_write.h b/include/asm-generic/audit_dir_write.h
> index 7b61db4..5282aba 100644
> --- a/include/asm-generic/audit_dir_write.h
> +++ b/include/asm-generic/audit_dir_write.h
> @@ -29,4 +29,5 @@ __NR_unlinkat,
>  __NR_renameat,
>  __NR_linkat,
>  __NR_symlinkat,
> +__NR_unlinkat_s,
>  #endif
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 9ab779e..039e969 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1594,6 +1594,7 @@ struct super_operations {
>         int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
>         long (*nr_cached_objects)(struct super_block *, int);
>         long (*free_cached_objects)(struct super_block *, long, int);
> +       void (*set_secure_delete) (struct super_block *, bool);
>  };
>
>  /*
> diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
> index bda9b81..b88019b 100644
> --- a/include/linux/syscalls.h
> +++ b/include/linux/syscalls.h
> @@ -877,4 +877,5 @@ asmlinkage long sys_seccomp(unsigned int op, unsigned int flags,
>  asmlinkage long sys_getrandom(char __user *buf, size_t count,
>                               unsigned int flags);
>  asmlinkage long sys_bpf(int cmd, union bpf_attr *attr, unsigned int size);
> +asmlinkage long sys_unlinkat_s(int dfd, const char __user * pathname, int flag);
>  #endif
> diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h
> index 22749c1..2ba072e 100644
> --- a/include/uapi/asm-generic/unistd.h
> +++ b/include/uapi/asm-generic/unistd.h
> @@ -707,9 +707,11 @@ __SYSCALL(__NR_getrandom, sys_getrandom)
>  __SYSCALL(__NR_memfd_create, sys_memfd_create)
>  #define __NR_bpf 280
>  __SYSCALL(__NR_bpf, sys_bpf)
> +#define __NR_unlinkat_s 281
> +__SYSCALL(__NR_unlinkat_s, sys_unlinkat_s)
>
>  #undef __NR_syscalls
> -#define __NR_syscalls 281
> +#define __NR_syscalls 282
>
>  /*
>   * All syscalls below here should go away really,
> diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> index fb12645..1507335 100644
> --- a/tools/perf/builtin-trace.c
> +++ b/tools/perf/builtin-trace.c
> @@ -1110,6 +1110,8 @@ static struct syscall_fmt {
>         { .name     = "uname",      .errmsg = true, .alias = "newuname", },
>         { .name     = "unlinkat",   .errmsg = true,
>           .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */ }, },
> +       { .name     = "unlinkat_s",   .errmsg = true,
> +         .arg_scnprintf = { [0] = SCA_FDAT, /* dfd */ }, },
>         { .name     = "utimensat",  .errmsg = true,
>           .arg_scnprintf = { [0] = SCA_FDAT, /* dirfd */ }, },
>         { .name     = "write",      .errmsg = true,
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Michael Kerrisk]

Alexander,

On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
>
>> The fact is that the current patches are useless for anything other
>> than proof-of-concept. Now you know more that needs to be done or
>
>
> That's wrong. The patches already work. If you delete a file which isn't in
> use by something else, the current contents will be wiped on traditional
> harddrives. I assume that already fulfills more than 50% of use cases of
> ordinary people.

You are getting various feedback from people, that you seem to be ignoring.

Al Viro, in his curmedgeonly way, points out that the problems are
much deeper than you realize. He does not say so explicitly, but I
imagine his point is that he does not want to see the kernel cluttered
with "partial" solutions that will simply increase the maintenance
burden in the long term, and leave bugs to be fixed further down the
line. You seem not to be listening.

Lukáš points out to you that getting a feature like this into the
kernel is complex process. You seem unwilling to hear that, and still
just want your partial solution.

I tell you that discussions of APIs should CC linux-api, which I am
now CCing into this thread, again, because, again, you're not
listening to feedback.

Nobody is asking for "high towers"; they just have their eyes on the
big picture. And the people here are just "ordinary people" with a
*lot* of experience dealing with kernel code (I exclude myself) . They
see many complexities that you don't. Getting intersting features into
the kernel requires a lot of work, and careful listening.

Thanks,

Michael


-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface", http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 14:06 schrieb Michael Kerrisk:
> Alexander,
>
> On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>> Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
>>
>>> The fact is that the current patches are useless for anything other
>>> than proof-of-concept. Now you know more that needs to be done or
>>
>>
>> That's wrong. The patches already work. If you delete a file which isn't in
>> use by something else, the current contents will be wiped on traditional
>> harddrives. I assume that already fulfills more than 50% of use cases of
>> ordinary people.
>
> You are getting various feedback from people, that you seem to be ignoring.

I'm happy for all the feedback. But it doesn't help me. I'm not going to 
spend the necessary time unpaid.
.
> Al Viro, in his curmedgeonly way, points out that the problems are
> much deeper than you realize. He does not say so explicitly, but I
> imagine his point is that he does not want to see the kernel cluttered
> with "partial" solutions that will simply increase the maintenance
> burden in the long term, and leave bugs to be fixed further down the
> line. You seem not to be listening.

It doesn't help me nor anyone else. As Eric Sandeen made me aware 
through in bug, look at http://lwn.net/Articles/462437/ what already 
happened.

> Lukáš points out to you that getting a feature like this into the
> kernel is complex process. You seem unwilling to hear that, and still
> just want your partial solution.

Wrong. I don't want my partial solution to be part of the official 
kernel. I don't care. I offered it for other users because I'm aware 
that has become almost impossible for normal people to get something 
into the kernel without spending an unbelievable amount of time most 
people can't afford to spend.

> I tell you that discussions of APIs should CC linux-api, which I am
> now CCing into this thread, again, because, again, you're not
> listening to feedback.

Please don't confuse "not listening" with "unable to fulfill Linux 
kernel maintainer requests".

Alexander Holler

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 14:21 schrieb Alexander Holler:

>> I tell you that discussions of APIs should CC linux-api, which I am
>> now CCing into this thread, again, because, again, you're not
>> listening to feedback.
>
> Please don't confuse "not listening" with "unable to fulfill Linux
> kernel maintainer requests".

I really wonder what do you expect from people not getting paid to spend 
time for fulfilling maintainer request?

I've written bugs and even offered some patches (regardless how usefull 
there are in your eyes, it's more than most other people can do).

And all what it brought me is that I receive flames like your one.

Do you really think that's the right way to stimulate people in helping 
to make Linux better?

Alexander Holler

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 14:29 schrieb Alexander Holler:
> Am 04.02.2015 um 14:21 schrieb Alexander Holler:
>
>>> I tell you that discussions of APIs should CC linux-api, which I am
>>> now CCing into this thread, again, because, again, you're not
>>> listening to feedback.
>>
>> Please don't confuse "not listening" with "unable to fulfill Linux
>> kernel maintainer requests".
>
> I really wonder what do you expect from people not getting paid to spend
> time for fulfilling maintainer request?
>
> I've written bugs and even offered some patches (regardless how usefull
> there are in your eyes, it's more than most other people can do).
>
> And all what it brought me is that I receive flames like your one.
>
> Do you really think that's the right way to stimulate people in helping
> to make Linux better?

I'm really sorry that I can't spend several unpaid months with reading 
and understanding ever changing linux kernel sources in order to become 
a Linux filesystem expert and send some fully working perfect patches 
which do fix the problem in question.

And I can't spend the necessary time to play remote keyboard for kernel 
maintainers which might be willing to explain me what has to be done 
according to their view. I've already offered what I was willing to do, 
for the price of having to defend myself over and over. And 
unfortunately that wasn't the first time I've ended up with having to 
defend myself.

My conclusion is that I'm a real fool having posted multiple times 
patches to this list. It just doesn't make any sense and most of the 
time the only reward are flames.

Alexander Holler

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Austin S Hemmelgarn]

On 2015-02-04 09:19, Alexander Holler wrote:
> Am 04.02.2015 um 14:29 schrieb Alexander Holler:
> I'm really sorry that I can't spend several unpaid months with reading
> and understanding ever changing linux kernel sources in order to become
> a Linux filesystem expert and send some fully working perfect patches
> which do fix the problem in question.
You aren't expected to do so.  Code review is an integral part of the 
development process here, and only truly trivial patches (stuff like 
fixing typos in kernel messages and documentation) get merged without 
it.  If you pay attention to the list itself, even the veteran kernel 
developers almost never manage to produce a patch that is deemed 
absolutely perfect, and end up revising things multiple times before 
they get merged.
> And I can't spend the necessary time to play remote keyboard for kernel
> maintainers which might be willing to explain me what has to be done
> according to their view. I've already offered what I was willing to do,
> for the price of having to defend myself over and over. And
> unfortunately that wasn't the first time I've ended up with having to
> defend myself.
You seem to fail to understand that open source development runs 
primarily on volunteer work (yes there are people paid to work on open 
source software, but that is a generally exceptional case).  A large 
majority of the people who are kernel maintainers are donating their 
free time to the project.
> My conclusion is that I'm a real fool having posted multiple times
> patches to this list. It just doesn't make any sense and most of the
> time the only reward are flames.
If you aren't serious about trying to get something into the mainline 
kernel, you should be tagging _all_ of the e-mails in that patch-set 
with [RFC] in the subject line.

In none of the responses that I've seen has anyone been anything but 
polite (albeit in some cases moderately annoyed).  If you really 
consider such attempts at constructive criticism to be flames, then a 
development mailing list isn't the place you should be posting patches.

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3708 bytes --]

On Wed, 4 Feb 2015, Alexander Holler wrote:

> Date: Wed, 04 Feb 2015 14:21:12 +0100
> From: Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
> To: Michael Kerrisk <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Cc: Lukáš Czerner <lczerner-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
>     Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>,
>     Linux-Fsdevel <linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>     Linux Kernel <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
>     Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
> 
> Am 04.02.2015 um 14:06 schrieb Michael Kerrisk:
> > Alexander,
> > 
> > On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler <holler-SXC+2es9fhnfWeYVQQPykw@public.gmane.org>
> > wrote:
> > > Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
> > > 
> > > > The fact is that the current patches are useless for anything other
> > > > than proof-of-concept. Now you know more that needs to be done or
> > > 
> > > 
> > > That's wrong. The patches already work. If you delete a file which isn't
> > > in
> > > use by something else, the current contents will be wiped on traditional
> > > harddrives. I assume that already fulfills more than 50% of use cases of
> > > ordinary people.
> > 
> > You are getting various feedback from people, that you seem to be ignoring.
> 
> I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
> the necessary time unpaid.

Right, you'd much rather have someone else to spend the time on your
request unpaid. That's understandable, but unreasonable. You want
it, implement it, or pay someone else to do it for you.

> .
> > Al Viro, in his curmedgeonly way, points out that the problems are
> > much deeper than you realize. He does not say so explicitly, but I
> > imagine his point is that he does not want to see the kernel cluttered
> > with "partial" solutions that will simply increase the maintenance
> > burden in the long term, and leave bugs to be fixed further down the
> > line. You seem not to be listening.
> 
> It doesn't help me nor anyone else. As Eric Sandeen made me aware through in
> bug, look at http://lwn.net/Articles/462437/ what already happened.

That's what people have been trying to tell you. It's not an easy
task and there are plenty of cases to think about. As you can see
IBM tasked their developer to do it, but they did not succeed. And
here you come with your simplistic patches crying about "high
towers. But you're the one apparently interested in this feature
and you've been warned that's it's not a simple task.

But if you really want it I really do encourage you to try. I'd be
happy to have a working and reliable secure delete feature but it's
not my priority at all.

-Lukas

> 
> > Lukáš points out to you that getting a feature like this into the
> > kernel is complex process. You seem unwilling to hear that, and still
> > just want your partial solution.
> 
> Wrong. I don't want my partial solution to be part of the official kernel. I
> don't care. I offered it for other users because I'm aware that has become
> almost impossible for normal people to get something into the kernel without
> spending an unbelievable amount of time most people can't afford to spend.
> 
> > I tell you that discussions of APIs should CC linux-api, which I am
> > now CCing into this thread, again, because, again, you're not
> > listening to feedback.
> 
> Please don't confuse "not listening" with "unable to fulfill Linux kernel
> maintainer requests".
> 
> Alexander Holler
> 
> 

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
> On Wed, 4 Feb 2015, Alexander Holler wrote:

>> I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
>> the necessary time unpaid.
> 
> Right, you'd much rather have someone else to spend the time on your
> request unpaid. That's understandable, but unreasonable. You want
> it, implement it, or pay someone else to do it for you.

Maybe you should attach a big fat red warning to the kernels bugzilla
that filing a bug means either to fix it yourself or pay somone to do that.

I've never demanded that someone else fixes it.

I've just explained a problem.

Unbelievable how someone could do such without paying someone else to
fix it or by fixing it themself ...

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Lukáš Czerner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1350 bytes --]

On Wed, 4 Feb 2015, Alexander Holler wrote:

> Date: Wed, 04 Feb 2015 17:12:52 +0100
> From: Alexander Holler <holler@ahsoftware.de>
> To: Lukáš Czerner <lczerner@redhat.com>
> Cc: Michael Kerrisk <mtk.manpages@gmail.com>,
>     Al Viro <viro@zeniv.linux.org.uk>, Theodore Ts'o <tytso@mit.edu>,
>     Linux-Fsdevel <linux-fsdevel@vger.kernel.org>,
>     Linux Kernel <linux-kernel@vger.kernel.org>,
>     Linux API <linux-api@vger.kernel.org>
> Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
> 
> Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
> > On Wed, 4 Feb 2015, Alexander Holler wrote:
> 
> >> I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
> >> the necessary time unpaid.
> > 
> > Right, you'd much rather have someone else to spend the time on your
> > request unpaid. That's understandable, but unreasonable. You want
> > it, implement it, or pay someone else to do it for you.
> 
> Maybe you should attach a big fat red warning to the kernels bugzilla
> that filing a bug means either to fix it yourself or pay somone to do that.
> 
> I've never demanded that someone else fixes it.
> 
> I've just explained a problem.
> 
> Unbelievable how someone could do such without paying someone else to
> fix it or by fixing it themself ...

It's not a bug, you're requesting a feature.

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 17:25 schrieb Lukáš Czerner:
> On Wed, 4 Feb 2015, Alexander Holler wrote:

>> Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
>>> On Wed, 4 Feb 2015, Alexander Holler wrote:
>>
>>>> I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
>>>> the necessary time unpaid.
>>>
>>> Right, you'd much rather have someone else to spend the time on your
>>> request unpaid. That's understandable, but unreasonable. You want
>>> it, implement it, or pay someone else to do it for you.
>>
>> Maybe you should attach a big fat red warning to the kernels bugzilla
>> that filing a bug means either to fix it yourself or pay somone to do that.
>>
>> I've never demanded that someone else fixes it.
>>
>> I've just explained a problem.
>>
>> Unbelievable how someone could do such without paying someone else to
>> fix it or by fixing it themself ...
>
> It's not a bug, you're requesting a feature.
>

Ok, I'm guilty.

May I ask if there's somewhere a feature request tracker which doesn't 
cruzify someone because he suggest a (maybe wrong) solution and tries to 
show that this might work with some prelimary, broken, silly, quick and 
dirty patches?

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 17:45 schrieb Alexander Holler:
> Am 04.02.2015 um 17:25 schrieb Lukáš Czerner:
>> On Wed, 4 Feb 2015, Alexander Holler wrote:
>
>>> Am 04.02.2015 um 15:52 schrieb Lukáš Czerner:
>>>> On Wed, 4 Feb 2015, Alexander Holler wrote:
>>>
>>>>> I'm happy for all the feedback. But it doesn't help me. I'm not
>>>>> going to spend
>>>>> the necessary time unpaid.
>>>>
>>>> Right, you'd much rather have someone else to spend the time on your
>>>> request unpaid. That's understandable, but unreasonable. You want
>>>> it, implement it, or pay someone else to do it for you.
>>>
>>> Maybe you should attach a big fat red warning to the kernels bugzilla
>>> that filing a bug means either to fix it yourself or pay somone to do
>>> that.
>>>
>>> I've never demanded that someone else fixes it.
>>>
>>> I've just explained a problem.
>>>
>>> Unbelievable how someone could do such without paying someone else to
>>> fix it or by fixing it themself ...
>>
>> It's not a bug, you're requesting a feature.
>>
>
> Ok, I'm guilty.
>
> May I ask if there's somewhere a feature request tracker which doesn't
> cruzify someone because he suggest a (maybe wrong) solution and tries to
> show that this might work with some prelimary, broken, silly, quick and
> dirty patches?

I guess the answer is FreeBSD or similiar. ;)

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Theodore Ts'o]

On Wed, Feb 04, 2015 at 03:52:02PM +0100, Lukáš Czerner wrote:
> > I'm happy for all the feedback. But it doesn't help me. I'm not going to spend
> > the necessary time unpaid.
> 
> Right, you'd much rather have someone else to spend the time on your
> request unpaid. That's understandable, but unreasonable. You want
> it, implement it, or pay someone else to do it for you.
> 
> > It doesn't help me nor anyone else. As Eric Sandeen made me aware through in
> > bug, look at http://lwn.net/Articles/462437/ what already happened.
> 
> That's what people have been trying to tell you. It's not an easy
> task and there are plenty of cases to think about. As you can see
> IBM tasked their developer to do it, but they did not succeed. And
> here you come with your simplistic patches crying about "high
> towers. But you're the one apparently interested in this feature
> and you've been warned that's it's not a simple task.

And indeed, people who do have salaries paid by companies who care
about this general problem in actual products have been working on
addressing it using encryption, such that when the user is removed
from the device, the key is blasted.  More importantly, when the user
is not logged in, the key isn't even *available* on the device.  So it
solves more problems than the one that you are concerned about, and in
general maintainers prefer solutions that solve multiple problems,
because that minimizes the number of one-time hacks and partial/toy
solutions which turn into long-term maintainance headaches.  (After
all, if you insist on having a partial/toy solution merged, that turns
into an unfunded mandate which the maintainers effectively have to
support for free, forever.)

You've rejected encryption as a proposed solution as not meeting your
requirements (which if I understand your objections, can be summarized
as "encryption is too hard").  This is fine, but if you want someone
*else* to implement your partial toy solution which is less secure,
then you will either need to pay someone to do it or do it yourself.

> > Wrong. I don't want my partial solution to be part of the official kernel. I
> > don't care. I offered it for other users because I'm aware that has become
> > almost impossible for normal people to get something into the kernel without
> > spending an unbelievable amount of time most people can't afford to spend.

So you expect other users to just apply your patches and use an
unofficial system call number that might get reassigned to some other
user later on?

If that's all you want, then ok, you're done.  The patches have been
posted to LKML, and you can give people URL's if they want to try
applying the patches on their own.

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

[Alexander Holler]

Am 04.02.2015 um 20:33 schrieb Theodore Ts'o:

> And indeed, people who do have salaries paid by companies who care
> about this general problem in actual products have been working on
> addressing it using encryption, such that when the user is removed
> from the device, the key is blasted.  More importantly, when the user
> is not logged in, the key isn't even *available* on the device.  So it
> solves more problems than the one that you are concerned about, and in
> general maintainers prefer solutions that solve multiple problems,
> because that minimizes the number of one-time hacks and partial/toy
> solutions which turn into long-term maintainance headaches.  (After
> all, if you insist on having a partial/toy solution merged, that turns
> into an unfunded mandate which the maintainers effectively have to
> support for free, forever.)

It's just another layer above and an rather ugly workaround which ends 
up in having to manage keys and doesn't solve the real problem. Besides 
that it's much more complicated especially in kind of kernel sources to 
manage.

> You've rejected encryption as a proposed solution as not meeting your
> requirements (which if I understand your objections, can be summarized
> as "encryption is too hard").  This is fine, but if you want someone
> *else* to implement your partial toy solution which is less secure,
> then you will either need to pay someone to do it or do it yourself.

I haven't rejected it. I'm using that myself since around 10 years, 
because of the impossibility to really delete files when using Linux.

>>> Wrong. I don't want my partial solution to be part of the official kernel. I
>>> don't care. I offered it for other users because I'm aware that has become
>>> almost impossible for normal people to get something into the kernel without
>>> spending an unbelievable amount of time most people can't afford to spend.
>
> So you expect other users to just apply your patches and use an
> unofficial system call number that might get reassigned to some other
> user later on?

People do such all the time because the mainline kernel is otherwise 
unusable on many boards.

Besides that, I don't expect that anyone uses my patches.

As said multiple times before, they are an offer and were primarily 
meant to show a possible simple solution for many use cases. They 
already work with inside some, of course maybe uncomfortable, limits and 
don't do any worse. just better.

Alexander Holler