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
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