Miloslav Trmač writes:
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik
<mrsam(a)courier-mta.com>
wrote:
> Chris Adams writes:
>
>> Once upon a time, Sam Varshavchik <mrsam(a)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.
Not quite. Although renaming over an exe is certainly a tradition, it is not
something that happens randomly, at no particular time. It's always a result
of a controlled process, such as a scheduled upgrade.
Prelink runs …whenever. I don't think there's a precedent for having some
maintenance system process of randomly renaming over running executables
that it has absolutely no relation to.
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 did not say that this is all of authentication. Sent credentials over the
filesystem domain socket include not just the pid, but the userid and the
groupid, of course.
> 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.
That would be a valid concern, certainly. So, I suppose, it's either take
prelink as it is, or not. There is apparently, no good solution to prelink
arbitrarily renaming over an executable, and breaking the documented /proc
API in proc(5), at any time.