Some geeky traditions did continue in 2020, including FOSDEM — the Free and Open Source Software Developers' European Meeting. The special 20th-anniversary edition still went off as scheduled in Brussels in early February, giving the community's developers a chance to hear from one another. And last week the videos finally appeared online — including a…
Not at all. File access control in UNIX works just fine, but no kernel-based access control can protect all user homes against a successful privilege escalation. Encryption, instead, does.
The idea that erasing keys is pointless is also incorrect: it’s possible to implement proper scrubbing of keys and caches in RAM, and also CPU registers, CPU caches and so on. Once the sensitive content is wiped the kernel can be compromised by an attacker but the data will not be immediately at risk.
What I am saying is that if you have access to RAM (e.g. via https://en.wikipedia.org/wiki/IEEE_1394#Security_issues or in general https://en.wikipedia.org/wiki/DMA_attack) then not all content of your files is secure unless you “scrub” the entire content of RAM.
So if you were to scrub page cache, loaded programs will still have some or all parts of the files loaded in RAM. E.g. my vim process will have some of my source code loaded. My SSH agent will have my keys loaded in RAM, my browser will have the very text you are reading loaded in RAM.
So scrubbing keys from RAM will protect most of your data but not all of your data - false sense of security. So you better understand that trade-off before using such proposed system. It is still better than having you disk wide open but it will never be perfect.
Now you are shifting the goalposts.
This is not a design flaw in LUKS or in ACLs. Applications can be closed, the SSH agent can scrub its memory and so on.