Date: Thu, 9 Aug 2018 10:52:59 -0400 From: Mark Johnston <markj@freebsd.org> To: "Patrick M. Hausen" <hausen@punkt.de> Cc: freebsd-virtualization@freebsd.org Subject: Re: Why can't I dtrace processes running in a jail from the host? Message-ID: <20180809145258.GA68459@raichu> In-Reply-To: <FB08F1C9-C066-4C78-8D35-E2A522ADC8F8@punkt.de> References: <FB08F1C9-C066-4C78-8D35-E2A522ADC8F8@punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 09, 2018 at 01:09:00PM +0200, Patrick M. Hausen wrote: > Hi all, > > I'm wondering why on a busy hosting server with hundreds of PHP-FPM > workers running in jails "dtrace -l" on the host does not show any > PHP specific probes. PHP *is* compiled with dtrace support for all the > jails. > > Enabling /dev/dtrace/* via devfs.rules for a specific jail and then repeating > the process *inside* the jail works as expected. > > Shouldn't jailed processes be transparently visible from the host system > but not vice versa? For userland static probes to be globally visible, the process needs to register them with the kernel when it starts. This is done automatically using a constructor which issues ioctls to /dev/dtrace/helper, hence the requirement for /dev/dtrace/* in the jail. In general it is still possible to use unregistered userland probes in this scenario: dtrace(1) can discover them when it attaches to a specified process. I'm not sure how well this will work if the process is jailed and dtrace(1) is invoked on the host, but it's worth trying. I would be rather wary of enabling access to /dev/dtrace/* in a jail. The kernel code which parses probe metadata has a large attack surface and has had security holes in the past.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180809145258.GA68459>