On 2015-09-20 06:41, Alexander Holler wrote:
First off, this is why I will never live in the UK. Secondly, this is why if it's something that you don't want to store for a long time (that is, longer than the system will be powered on), you use an ephemeral encryption key. Thirdly, if there is some chance you can lose the key, you make a secure backup (or do like I do and algorithmically generate passwords/encryption keys in a reproducible manner (which is itself secure if you do it right, and of course tell no-one the algorithm you use to generate them)).Am 20.09.2015 um 04:21 schrieb Theodore Ts'o:On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote:Perhaps not so surprisingly, over a decade later, it is not currently at the top of the priority list of any of the current file system or VFS developers, as far as I know. One of the reasons for that is that there are a number of other ways of achieving the same functionality. These include using tmpfs, or using file system level encryption. They require a bit more system administrator setup than just being able to set the FS_SECR_FL flag, true, but just because it's more convenient doesn't mean that it's worth doing.Again, I don't think that encryption is an alternative. Besides that there is always the thread that strong encrytion will become regulated, there is also the very real thread that someone might end up in jail when using encryption and throwing away the key to delete stuff. E.g., as to my knowledge, in the UK you might end up in jail if you don't hand out a password. So what happens if you've deleted the key and are really unable to hand it out and the people which have an interest in what you've once stored don't believe you?
So.... this is a feature request. It's a reasonable feature request, in that if someone would like to pay $$$ for some consultant to implement it in a way that is bug-free, I suspect it could go upstream. Someone who was very motivated and with the sufficient skills could also invest their own effort to make a patch that can go upstream too. You've elected not, to because you believe it would take you months of "unpaid time". That's purely within your rights to do. But you don't have the right to try to tell other people what work to do on their behalf --- not unless you are paying their salary.First I haven't request that someone implements it for me. Besides that what you're describing is what maintainers do all the time. Of course, it's their job to request quality, but, in my humble opinion, very often they are requesting stuff just to request something.
The problem I see with this argument is:1. There's a lot of code in the kernel that wouldn't be merged today in the state it's in, this creates a false sense of what quality is expected for new code (BTRFS in particular comes to mind here). 2. If the code can be proven to be racy, you fix it, period. Adding known racy code to the kernel should never happen. The same goes for unsafe usage of locking, RCU, or any subsystem related macros/functions. This should probably be better spelled out in SubmittingPatches. 3. Subsystem maintainers became maintainers because they have a very high degree of knowledge relating to that subsystem, and usually about general kernel programming as well. If a maintainer is asking you to fix something in your patch, I'd be more than willing to bet that they are right in asking you to fix it.
Discard has never really worked properly in BTRFS, although it is being worked on. If you actually care about security though, you shouldn't be using discard except when re-provisioning your storage (there are numerous papers about why on the web), trying to use that for secure deletion is creating a false sense of security.And that "month of unpaid time" was for sure a cynical exaggeration I've done while having been angry. In fact I believe the way I've outlined with the ugly code (proof of concept) could be implemented by someone like you in a weekend. For me it needs quiet some more time because I had and still have almost zero knowledge about all locks and whatever else is used in the filesystem code. But nevertheless I was able to fix up a lot of stuff during another afternoon. E.g. I've added checks if a file is in use or if AT_WIPE was called on a directory and then returned errors in those cases. Unfortunately the code changed in 4.2 and that patch doesn't apply anymore and now, because I don't really need those implementation details (I'm aware of the problems of my patch), I've thrown the patch into the waste bin. Besides that my concept doesn't work on BTRFS what I'm currently using for various reasons (mainly compression) on most of my systems. And I have no idea if it ever will (because I don't know why discard on BTRFS doesn't really discard what I think it should discard. ;) ).
If you're using in-line compression, then that at least means that it will take somewhat more effort to get a file off of the disk that has been deleted.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
