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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Ricardo Ribalda _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
