I have a possible explanation from a distribution perspective. lets say that you have a binary bin.elf that uses a.so and b.so. A.so is packaged in a.deb and b is packaged in b.deb and bin.elf bin.deb. When you are installing/upgrading bin.deb, the package knows how to stop/start bin.elf, so you can stop, upgrade, start When you are installing/upgrading b.deb the package does not know how many binaries are using b.so. It would be pretty nasty to do a kill $(lsof | grep), because there are some services that require some extra steps to turn them on. There is probably another explanation from other perspectives. Cheers! On Fri, Nov 10, 2017 at 2:30 PM, Lev Olshvang <levonshe@yandex.com> wrote:
Hi list
The reason for my question is mainly security context.
Here the story If you ever tried to replace executable file by new image the message executable is busy appeared and operation fails.
But the attempt to replace shared object library succeeded, and I do not understand the logic of this decision.
Besides to be security hole, I do not see any legitimate use except of live patching of shared object. I do not know whether production or mission critical system may take a risk of live patching, but development system would do a library update by stopping dependent application first.
I saw in kernel archives that some years ago the decision was made to withdraw restriction on shared object live replacement and I would like to know the what what were the reasons because I want to patch my kernel to forbid shared objects live replacement. ( as I said I worry about security issue)
Regards, Lev
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- Ricardo Ribalda