Oleg Nesterov <oleg@xxxxxxxxxx> writes: > On 09/23, Jann Horn wrote: >> >> This is a new per-threadgroup lock that can often be taken instead of >> cred_guard_mutex and has less deadlock potential. > > Oh, please don't. > >> I'm doing this because >> Oleg Nesterov mentioned the potential for deadlocks, in particular if a >> debugged task is stuck in execve, trying to get rid of a ptrace-stopped >> thread, and the debugger attempts to inspect procfs files of the debugged >> task. > > Yes, but we need to fix this anyway. And I am not sure the new mutex can > actually help. > > 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. At which point exec (which changes the mm) should not be an issue. But we definitely should be able to check permissions on open (possibly including grabbing resources) and then perform the work. Eric -- 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
