Why replacing running executable file is forbidden, but overwriting of memory mapped shared object is allowed ?

[Ricardo Ribalda Delgado]

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 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)
>
> Regards,
> Lev
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Ricardo Ribalda