From owner-freebsd-current Wed Sep 11 10: 9:39 2002 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 BB79E37B47C for ; Wed, 11 Sep 2002 10:09:20 -0700 (PDT) Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 513C643E42 for ; Wed, 11 Sep 2002 10:09:20 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 9324 invoked from network); 11 Sep 2002 17:09:16 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 11 Sep 2002 17:09:16 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.5/8.12.5) with ESMTP id g8BH9HBv035521; Wed, 11 Sep 2002 13:09:17 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200209110609.g8B68xwr096967@gw.catspoiler.org> Date: Wed, 11 Sep 2002 13:09:18 -0400 (EDT) From: John Baldwin To: Don Lewis Subject: Re: Locking problems in exec Cc: wollman@lcs.mit.edu, current@FreeBSD.ORG, nate@root.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 11-Sep-2002 Don Lewis wrote: > On 10 Sep, Don Lewis wrote: >> On 10 Sep, Nate Lawson wrote: >> >>> I'm not sure why fdcheckstd() and setugidsafety() couldn't both happen >>> before grabbing the proc lock. Dropping locks in the middle or >>> pre-allocating should always be a last resort. >> >> That is ok as long as there aren't other threads that can mess things up >> after fdcheckstd() and setugidsafety() have done their thing. > > It looks like threads aren't a problem because of the call to > thread_single() at the top of execve(). Ptrace() is still a potential > problem, so we can't call fdcheckstd() and setugidsafety() until after > credential_changing has been calculated, setsugid() has been called and > tracing has been disabled, all of which are done after proc lock has > been grabbed. > > It also looks like we should pre-allocate newprocsig instead of > temporarily dropping the lock. We used to do that but backed it out because it wasn't deemed to be that necessary. If you have a demonstrable problematic race condition that this fixes then it might be a good idea. However, allocating stuff we don't need isn't but so great either. I think ptrace(2) is not an issue because ptrace(2) won't attach to a P_INEXEC process IIRC. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message