Wasn't meaning it would be the executable. It would be a data file.

Yes, having a separate per-user configuration file would solve ETXTBSY problem, but mmap still won’t solve synchronisation so it doesn’t really matter if the file is mmaped or simply opened with (f)open – to synchronise access flock would have to be used anyway.

Yes. But at least it would work for more than just the owner of the executable (and the directory the executable is in). It would also eliminate the complaint about having to parse the file...

BTW, What the op is doing is the way a virus would have to work...

I got into this with just an innocent query in my mind, "Could this work?" I had a couple bytes of state data and I wanted to avoid writing a config file and all the parse code for it.

Very quickly I realized this could have evil intent. Look at how so many Linux users nowadays just blindly install the binary packages from their favorite distro. These programs could be doing anything besides what they claim to be doing. This is certainly how to spread virus in linux: infect a whole distro from 1 innocent looking utility/lib upgrade. The code to make this happen is tiny, and could easily be hidden in the source with a couple funny looking macros. Someone would need to look very close to find it.

There's a lot of naivete in the Linux community. This bothers me, and SELinux is not the answer.

As a closely related sidenote: I recently got a new desktop PC and proceeded to install fresh Linux on it, which I have not done in about 10 years. After about 10 or 12 different distros, I find myself actually writing my own /sbin/init so I can bypass systemd and all that bloat. I have a fully working system with X and WM that takes <30 seconds from reboot to login, and most of that is BIOS/POST. I'll probably end up using systemd, just because everything expects systemd, but I don't trust systemd. It's all opaque binaries, no sysvinit shell scripts anymore. Now nobody knows what the heck is going on. What happened to Linux in 10 years?

BTW, if your initrd works properly, here's a drop in replacement for /sbin/init(systemd):
Now THAT reminds me of Linux

Actually, this is blocked by even the simple things.

First, as the OP found, you can't modify a running executable.
Second, you have to copy the file before modifying it - thus, the copy of the file will be owned by the user running it.
Third, the file cannot be put back in the original place UNLESS the owner of the original file is the same as the user running it or have group write access to the directory containing the file...

Finally, SELinux can block all three.

The result is that the modified executable will not have the same owner, or security flags unless the user running the binary ALREADY owns the executable AND has the same security flags...

That only works for a single user mode. No network, no services...

If your base system uses systemd, then the way systemd has wormed its way into the system (currently, it starts in the initrd), it won't work either. agetty is now needed to login - guess what? You can't login as the needed systemd services to login aren't there. You have to replace "login" with one that doesn't depend on systemd (or at least replace the PAM modules that do...).

If you try to start the network.... it will also fail, unless you replace the various tools tied to systemd. You could manually start the network with ifconfig... But most of the services you would want to provide requires systemd...

If you want a system that works the traditional way, look at Slackware. So far, it has avoided systemd, partly by forking the projects that have been taken over by systemd, and partly by just being rather sane about it.

And as you say, it boots in under 30 seconds (my last check it was like 25 and that was using a VM; it would be faster with bare metal instead).

you don't have to use systemd
and probably never will

wish.

Nearly every desktop distribution (and a number of server versions) have switched to using systemd. Even some embedded systems use it.

whatever