On 09/30, Eric W. Biederman wrote: > > Oleg Nesterov <oleg@xxxxxxxxxx> writes: > > > And I think that cred_guard_mutex is already over-used in fs/proc. Say, > > I think lock_trace() must die, I simply can't understand why it is useful. > > > > Suppose we modify, say, proc_pid_stack() to do > > > > save_stack_trace_tsk(task, &trace); > > if (!ptrace_may_access(task, ...)) > > goto return -EPERM; > > > > for (i = 0; i < trace.nr_entries; i++) > > seq_printf(...); > > > > return 0; > > > > is there any problem if it shows some trace before setuid exec does > > install_exec_creds() ? > > You should make certain that the mm doesn't change in that picture, > perhaps like /proc/<pid>/mem does. Why? We do not care I think, /proc/pid/stack has nothing to do with task->mm. OK, we can use __ptrace_may_access() and call save_stack_trace_tsk() under task_lock(), but I don't understand why should we worry. And again, do you see any security problem with the code above? Yes, it is "racy" but I think it is fine to occasionally succeed when it races with credentials change. I fail to understand why the current code abuses cred_guard_mutex to close the race with setuid exec. Oleg. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
