Miloslav Trmač writes:
On Mon, Jul 16, 2012 at 4:20 AM, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> wrote:> Chris Adams writes: > >> Once upon a time, Sam Varshavchik <mrsam@xxxxxxxxxxxxxxx> 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.
Attachment:
pgp11NJCBEGOr.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
