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 <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
