From owner-freebsd-current@FreeBSD.ORG Fri Sep 5 01:20:51 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87BD316A4BF for ; Fri, 5 Sep 2003 01:20:51 -0700 (PDT) Received: from firecrest.mail.pas.earthlink.net (firecrest.mail.pas.earthlink.net [207.217.121.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id B49A643F93 for ; Fri, 5 Sep 2003 01:20:50 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfjg5.dialup.mindspring.com ([165.247.206.5] helo=mindspring.com) by firecrest.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19vBpT-00005w-00; Fri, 05 Sep 2003 01:20:28 -0700 Message-ID: <3F584702.82473957@mindspring.com> Date: Fri, 05 Sep 2003 01:19:14 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Wesley Morgan References: <1062686653.67807.77.camel@localhost> <20030904174858.L78363@volatile.chemikals.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a42c1063ce8e83d3f163c23ff9d3af21f1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Paul Richards cc: current@freebsd.org Subject: Re: Text file busy X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2003 08:20:51 -0000 Wesley Morgan wrote: > On Thu, 4 Sep 2003, Scott M. Likens wrote: > > On Thu, 2003-09-04 at 07:44, Paul Richards wrote: > > > Overwriting a file that's currently executing results in a "Text file > > > busy" error. > > > > this "feature" has always existed in FreeBSD for as long as I remember. > > It's also unfortunate that this protection does not seem to extend to > libaries. I've had some in-use X libraries get overwritten with some very > colorful results. So send patches. The specific problem is in the ld.so mapping of a page in a library file as "executable", and this mapping not setting the bit on the file image. In general, this isn't done because the other references to the file image may be as data (there's a race condition on install, and a security race, if the libraries are writable, that could permit a linked-shared SUID executable to be compromised after it's running, but then if it's writable at all, that exists anyway). So it's probably safe to do this without resource tracking the processes who've got it mapped this way. My ld.so currently differs significantly from the stock version, as does my C++ static constructor code, since I have a working static libdlopen on my own developement boxes, so the patches I have for this would be pretty useless for you, but they would be quite trivial to recreate; all you do is set the bit whem mmap has PROT_EXEC, or when mprotect has PROT_EXEC (both of these are used by ld.so; for the crt0.c startup code that loads ld.so initially, only mmap is used). -- Terry