On Thu, Jun 29, 2017 at 10:42 PM, Klemens Nanni <[email protected]> wrote: > On Thu, Jun 29, 2017 at 09:50:25PM -0700, Philip Guenther wrote: >> >> On Thu, Jun 22, 2017 at 7:17 PM, Klemens Nanni <[email protected]> wrote: >>> >>> So I just wrapped my head around vfs(9) with regard to making ktrace >>> following symlinks again, however I don't quite understand what problems >>> may occur when doing so. May anyone enlighten me on this? >> >> >> IMHO, it makes more sense to add fktrace(2) aka NetBSD where an open >> fd is passed in. > > To have a more generic interface?
Yes. ktrace -f - some_command | kdump Hmm, I wonder what happens if the fd involved is a pipe to the process being traced and if that will deadlock the kernel. Uh, hmm, could that happen as well with your suggestion to support FIFO if the traced process is the only reader, ala: mkfifio kt ktrace -f kt kdump -f /dev/stdin < kt ? It's okay if that just blocks, but it's not okay if it blocks processes that aren't being traced or if it eats the CPU. (VREG vnodes are exactly what the kernel can write to without having to worry about looping internally or userspace blocking it for arbitrary lengths of time. Well, at least if we ignore FUSE, which is basically ignored for this sort of discussion anyway, being a security nightmare. Anyone tried to ktrace a fuse-serving process, directing the ktrace to the fuse'd filesystem? Same question applies to acct() to a fuse'd filesystem, but at least that's root-only.) > Why not letting ktrace(2) handle this just like it already does for regular > files? *If* if it's safe (see above for an *example* consideration), then fd / struct file base access is much more general than filename / vnode based access. ktrace(1) *always* open()s the target filename, so would arguably remove a TOCTOU. Philip Guenther
