On Wed, 4 Feb 2015, Alexander Holler wrote:
Date: Wed, 04 Feb 2015 14:21:12 +0100
From: Alexander Holler <redacted>
To: Michael Kerrisk <redacted>
Cc: Lukáš Czerner <redacted>, Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
Theodore Ts'o [off-list ref],
Linux-Fsdevel [off-list ref],
Linux Kernel [off-list ref],
Linux API [off-list ref]
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)
Am 04.02.2015 um 14:06 schrieb Michael Kerrisk:quoted
Alexander,
On Wed, Feb 4, 2015 at 1:22 PM, Alexander Holler [off-list ref]
wrote:
quoted
Am 04.02.2015 um 13:07 schrieb Lukáš Czerner:
quoted
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.
.
quoted
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
quoted
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.
quoted
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
On Wed, Feb 04, 2015 at 03:52:02PM +0100, Lukáš Czerner wrote:
quoted
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.
quoted
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.
quoted
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
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.
quoted
quoted
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