On 3/2/20 4:57 PM, Eric W. Biederman wrote: > Bernd Edlinger <bernd.edlinger@xxxxxxxxxx> writes: > >> >> I tried this with s/EACCESS/EACCES/. >> >> The test case in this patch is not fixed, but strace does not freeze, >> at least with my setup where it did freeze repeatable. > > Thanks, That is what I was aiming at. > > So we have one method we can pursue to fix this in practice. > >> That is >> obviously because it bypasses the cred_guard_mutex. But all other >> process that access this file still freeze, and cannot be >> interrupted except with kill -9. >> >> However that smells like a denial of service, that this >> simple test case which can be executed by guest, creates a /proc/$pid/mem >> that freezes any process, even root, when it looks at it. >> I mean: "ln -s README /proc/$pid/mem" would be a nice bomb. > > Yes. Your the test case in your patch a variant of the original > problem. > > > I have been staring at this trying to understand the fundamentals of the > original deeper problem. > > The current scope of cred_guard_mutex in exec is because being ptraced > causes suid exec to act differently. So we need to know early if we are > ptraced. > It has a second use, that it prevents two threads entering execve, which would probably result in disaster. > If that case did not exist we could reduce the scope of the > cred_guard_mutex in exec to where your patch puts the cred_change_mutex. > > I am starting to think reworking how we deal with ptrace and exec is the > way to solve this problem. > > Eric >
