prelink should not mess with running executables

[Sam Varshavchik]

Miloslav Trmač writes:

> 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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120716/4a342123/attachment.sig>