prelink should not mess with running executables

Miloslav Trmač mitr at volny.cz
Mon Jul 16 05:24:19 UTC 2012


On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik <mrsam at courier-mta.com> wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik <mrsam at courier-mta.com> said:
>> > Chris Adams writes:
>> > >Is there anything that actually does that and depends on the result?
>>
>> You skipped this part.  Can you name something that tries this?  I bet
>> somebody can break it if so.
>
> When the code is ready, I'll name it, certainly, and I'll welcome anyone to
> attempt to break it. But that's just a sideshow. Whether something like this
> can or cannot be broken does not make what prelink does any more or less
> sensible.

What prelink does in this respect is perfectly sensible.  Being able
to rename() over an executable that is running is a long-standing UNIX
tradition, and prelink is only one of the manifestations of this.

As for the code authenticating via /proc/*/exe, _that's_ definitely
contrary to the UNIX model.  The race conditions have been already
mentioned, and they are a real concern - things like this have been
exploited in the past - but ultimately they are a side issue.  The
primary concern is that UNIX just nowhere, never, authenticates
executables - it authenticates identities attached to _running_
processes (UID, EUID, SELinux labels), it _never_ looks at the
executable file after execve() happens.  In particular, what good is
it to know that a process was started by running $a_specific_inode,
when the process might be under control of a ptracing parent, and
might currently be executing a completely different code not present
in that inode at all?


> I think that 99% of the problems that prelink is creating can be easily
> avoided simply by having prelink automatically skip executables that are
> currently running.

That would break prelink:
1) prelink would not prelink the most important executables, mostly
defeating its purpose.
2) The regular prelink run re-randomizes the whole system, assigning
non-conflicting addresses; without the ability to update all
executables, some of the addresses would conflict and require run-time
relocation, again defeating the purpose of prelink.
     Mirek


More information about the devel mailing list