Date: Wed, 11 Sep 2002 13:09:18 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: wollman@lcs.mit.edu, current@FreeBSD.ORG, nate@root.org Subject: Re: Locking problems in exec Message-ID: <XFMail.20020911130918.jhb@FreeBSD.org> In-Reply-To: <200209110609.g8B68xwr096967@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jhb@FreeBSD.org> <>< 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020911130918.jhb>