Re: Q: check_unsafe_exec() races (Was: [PATCH 2/4] fix setuid sometimes doesn't)

Al Viro
2009-03-30T01:14:23Z

On Mon, Mar 30, 2009 at 02:08:43AM +0100, Al Viro wrote:

> So...
> * one can always dereference current->fs
> * nobody can change task->fs for seen-by-scheduler task other than
> current (we can, of course, do that for a task we'd just allocated in clone
> before anyone else has seen it)
> * all changes of current->fs happen under task_lock *and* excl ->lock
> of old value of current->fs.
> * anybody can dereference task->fs while holding task_lock(task)
> * ->lock nests inside task_lock
> * freeing happens only when the last reference is gone *and* all
> tasks that used to hold such references has already gone through task_unlock
> * all refcount changes happen under excl ->lock
> * changes of ->root and ->pwd happen under excl ->lock
> * read access to ->root and ->pwd should be done under shared ->lock;
> to use the contents past the unlock you need to grab references to path in
> question while holding lock
> * cloning a reference is done while holding ->lock shared, fails with
^^^^^^
excl, of course

> -EAGAIN if fs_struct is marked "under exec"
> * mark in question is set and cleared with ->lock excl.
> * check_unsafe_exec() locks current->fs shared, goes through all
> threads comparing their ->fs with our, if the number doesn't match - bail
> out. Otherwise we mark it "under exec".
> * in the end of execve() (failure or success) we clear the mark.
> * all reassignments of task->fs are either to NULL or to new instance
> (never seen by anybody) or to &init_fs.
> * task with ->fs == &init_fs may not call execve(); those are kernel
> threads and they must get ->fs unshared before they can do anything of that
> kind (otherwise we'd have no end of trouble with chdir() done by exec'ed
> binary affecting hell knows what else).
>
> Does anybody see any holes in the above?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html