Date: Sat, 14 Sep 2002 08:25:50 -0700 (PDT) From: Don Lewis <dl-freebsd@catspoiler.org> To: nate@root.org Cc: current@FreeBSD.ORG Subject: Re: patch for lock recursion in execve() Message-ID: <200209141525.g8EFPowr008293@gw.catspoiler.org> In-Reply-To: <Pine.BSF.4.21.0209140245510.28837-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200209141525.g8EFPowr008293>