Re: ktrace: Following symlinks
On Thu, Jun 29, 2017 at 11:33:36PM -0700, Philip Guenther wrote: On Thu, Jun 29, 2017 at 10:42 PM, Klemens Nanni 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 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 kdump expects ktrace.out here and complains. 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 That one's interesting: kdump won't see data from kt on stdin since you're redirecting into ktrace. Here's an equivalent inocation that's more obvious: $ < kt ktrace -f kt -- kdump -f /dev/stdin ^Cksh: cannot open kt: Interrupted system call Neither ktrace nor kdump will actually be executed since the shell already chokes on it. You can check for that while it's still running (doing nothing): $ pgrep -fl k[td] $ Here's some more fun, trace yourself endlessly while eating CPU: $ ktrace -f - kdump -f - 58275 kle 54 0 648K 684K onproc/3 - 0:20 56.54% kdump -f - Or let ktrace wait forever (without -a the FIFO gets replaced and you'll see dumps just like above): $ mkfifo kt $ ktrace -af kt -- kdump -f kt 95073 root 2 0 128K 160K idle fifow 0:00 0.00% ktrace -af kt -- kdump -f 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. Playing around with it hasn't blocked other programs or crashed the kernel so far but I'll further look into this. (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.
Re: ktrace: Following symlinks
On Thu, Jun 29, 2017 at 10:42 PM, Klemens Nanni 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 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
Re: ktrace: Following symlinks
On Thu, Jun 29, 2017 at 09:50:25PM -0700, Philip Guenther wrote: On Thu, Jun 22, 2017 at 7:17 PM, Klemens Nanni 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? Why not letting ktrace(2) handle this just like it already does for regular files?
Re: ktrace: Following symlinks
On Thu, Jun 22, 2017 at 7:17 PM, Klemens Nanni 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. Philip Guenther
ktrace: Following symlinks
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? This feature was explicitly disabled 17 years ago[1] appearently because FreeBSD did so[2] but I couldn't find any further explanation. 1: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/kern/kern_ktrace.c.diff?r1=1.19&r2=1.20 2: https://svnweb.freebsd.org/base?diff_format=u&view=revision&revision=50668
