I'm seeing sandbox crash reports from content processes trying to call fstatat (__NR_newfstatat) with a directory fd (i.e., not AT_FDCWD) and a relative path. This would be nontrivial to handle with the file broker; basically, something would have to convert the fd to a path and concatenate it with the given relative path in order to get something that can be checked against the policy. That could be done in the child (calling the broker to readlink /proc/P/fd/N, doing async-signal-safe string arithmetic, then calling the broker again for the actual operation) or in the parent (passing the dir fd and the response socket with the requst), but either way it would need new code. And there are some edge cases where this won't do the same thing as the real fstatat (because it's non-atomic), which might be important. In the crash reports that we have, the syscall is coming from the ftw(3) file tree walker utility in glibc. I'm less clear about what's trying to do a tree walk and why — the stacks all involve Mesa drivers for ATi/AMD GPUs (r600_dri.so, radeonsi_dri.so), but I didn't find anything in the code that would be calling ftw or nftw, and I haven't found matching binaries in order to make sense of the offsets in the stack trace. Fortunately this isn't a very common crash, and the most recent report is from 2017-03-25.
You need to log in before you can comment on or make changes to this bug.