Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?
Ricardo Ribalda Delgado
ricardo.ribalda at gmail.com
Fri Nov 10 09:52:20 EST 2017
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.
On Fri, Nov 10, 2017 at 2:30 PM, Lev Olshvang <levonshe at 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)
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
More information about the Kernelnewbies