Can a file hide a program of the base? We tested it

Zainium OS keeps its base read-only, even for root. But the system you see is two layers joined together: the base below, and the software you install on top. In OverlayFS, a file in the top layer wins over a file below it with the same name.

So we asked a simple question. If root puts a file in the top layer with the same name as a base program, does it replace that program?

The test

We used a harmless target, the arch command, which prints x86_64. We put a small script in the top layer with the same name, one that prints SHADOWED.

The first result was confusing. arch still printed x86_64, but only because the kernel had remembered the old file. After we dropped the caches, it printed SHADOWED. The base file on disk had not changed at all, but programs now saw something else. That is not what a sealed system should allow.

The fix

There are two parts:

• In the kernel. In bin, sbin, libexec, lib, drivers and the musl folder, the base now always wins. A file in the top layer can not replace or hide a base file there, and neither can a whiteout, the special file that marks something as deleted. New files can still be added, so installing software works as before.
• At boot. quantra-ramfs looks for anything in the top layer that sits over a base program or library. It moves it to /overlayer/zexlib/shadowed and writes a warning to the boot log. Nothing is deleted.

The same kernel change also fixed a smaller bug: a new file over a remembered base file used to stay hidden for a while.

Testing it again

We ran the test again on the new kernel, in a VM and on a laptop, with the caches kept and with the caches dropped. We also tried a whiteout in the VM. The base won every time. Installing and removing a package still worked, with no reboot.

The boot check worked too. On the laptop, a leftover test file was found at boot and moved aside, and the warning was in the log.

What it costs

The fix is not free, so we measured it. We timed stat on the same file 200,000 times, three runs each, on the laptop:

The slower case is 2.4 times slower, about 7 microseconds, and it only happens for a file that is trying to hide a base file. Normal files do not pay this cost, and the boot check removes such files anyway.

What it does not fix

Root can still change settings in etc, change data in share, and use bind mounts until the next reboot. These limits are written down in how the system protects itself, and you can see what comes next on the roadmap.