From owner-freebsd-current Sat Sep 14 8:26: 1 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 07DC937B400 for ; Sat, 14 Sep 2002 08:25:59 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A5A943E42 for ; Sat, 14 Sep 2002 08:25:58 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Received: from mousie.catspoiler.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.5/8.12.5) with ESMTP id g8EFPowr008293; Sat, 14 Sep 2002 08:25:55 -0700 (PDT) (envelope-from dl-freebsd@catspoiler.org) Message-Id: <200209141525.g8EFPowr008293@gw.catspoiler.org> Date: Sat, 14 Sep 2002 08:25:50 -0700 (PDT) From: Don Lewis Subject: Re: patch for lock recursion in execve() To: nate@root.org Cc: current@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=US-ASCII 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 14 Sep, Nate Lawson wrote: > In short: execve has proc lock, calls setugidsafety. If a fd 0...2 > references procfs, it is closed via closef(), ... pfs_close(), pfind(), > dopfind() which tries to lock allprocs and then proc > lock. setugidsafety() should drop proc lock or be moved down a few lines > along with fdcheckstd() to be outside of proc lock. > > My only concern is if this opens up a race window where fds 0...2 could be > reopened to point to procfs. I'm fairly certain this is not possible but > would like some assurance before committing this. I believe we're safe: The P_INEXEC flag is set at the beginning of execve(), which is supposed to prevent this process from being molested by other processes. This flag remains set for most of the remainder of execve(). Just after P_INEXEC is set, thread_single() is called, which I believe kills off the other threads (or this thread dies at that point). Between where we decide to change id's and the call to setugidsafety(), we call setsugid(), which should keep this process from being attached other than by root. Syscall tracing is also explicitly turned off. My patch to unlock the proc lock for the call to fdcheckstd() was reviewed by jhb, who said: On 12 Sep, John Baldwin wrote: > On 11-Sep-2002 Don Lewis wrote: [major snippage] >> Do you think it is reasonable to >> temporarily drop the proc lock for the fdcheckstd() call? > > Yes. Between single-threading the process and P_INEXEC most of the > proc-related races in exec() are handled. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message