Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162003AbbBDT4l (ORCPT ); Wed, 4 Feb 2015 14:56:41 -0500 Received: from h1446028.stratoserver.net ([85.214.92.142]:40274 "EHLO mail.ahsoftware.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161229AbbBDT4f (ORCPT ); Wed, 4 Feb 2015 14:56:35 -0500 Message-ID: <54D27969.3090606@ahsoftware.de> Date: Wed, 04 Feb 2015 20:56:25 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Theodore Ts'o" , =?UTF-8?B?THVrw6HFoSBDemVybmVy?= , Michael Kerrisk , Al Viro , Linux-Fsdevel , Linux Kernel , Linux API Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only) References: <54D0C3B8.2050507@ahsoftware.de> <20150203174839.GD2509@thunk.org> <54D10D0E.8090204@ahsoftware.de> <20150203233332.GE29656@ZenIV.linux.org.uk> <54D1F215.9030404@ahsoftware.de> <54D20F02.5050700@ahsoftware.de> <54D21CC8.4020705@ahsoftware.de> <20150204193316.GH2509@thunk.org> In-Reply-To: <20150204193316.GH2509@thunk.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2718 Lines: 54 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 -- 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/