From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 13:47:10 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49827C1C for ; Wed, 4 Jun 2014 13:47:10 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06D362490 for ; Wed, 4 Jun 2014 13:47:09 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz11so8823211veb.31 for ; Wed, 04 Jun 2014 06:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FwCwlKN1Y0nHj2zMkZtzPbvnwnD3zv9+4M7Nnaef0Qk=; b=hm8FkYhaUBqOsf1rSbD2Ji4pfNUTB90VvYfTQZPd7JyE9ZqUwNQ/CDPD3Ht2yJGinH iPlKGeC2LVg0u46ijNBlzoRclM1Tz6kYT5n5vjtpIKipHr51b3nIrSgk91vwlOh2qyTl r/Ta7MnKz88KO+q6ZJCNwM7RPjCOszMMzC6iRXaTxcX7h7XJ8i5lyvFTOwh0B7oZNDsy 8+T3yn9Snkx0Z4Pg1yqb6SwubWUIm28JY3SmMaGxaLsqLNRnames/gsmOEhrDfR6rXWw 7E/FVPNg2KZR1r2WF5yqw/3TYQJDnkkzhzx+fDhUvaex2erlSPHK489dEE4Ip36pjt19 wJTg== MIME-Version: 1.0 X-Received: by 10.52.22.13 with SMTP id z13mr37309282vde.10.1401889629097; Wed, 04 Jun 2014 06:47:09 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Wed, 4 Jun 2014 06:47:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jun 2014 09:47:09 -0400 X-Google-Sender-Auth: InY36xugsDlxB0raYBIWoluUKwE Message-ID: Subject: Re: Postgresql provider no longer working From: Mark Johnston To: "Sevan / Venture37" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 13:47:10 -0000 On Wed, Jun 4, 2014 at 6:35 AM, Sevan / Venture37 wrote: > On 4 June 2014 02:45, Mark Johnston wrote: >> Hi, >> >> I can't reproduce this using postgres 9.3.4 on r267033 (current). As >> usual, it was necessary to first kldload dtraceall and make sure >> postgres could access /dev/dtrace/helper (in my case I've added the >> pgsql user to the wheel group). It's also necessary to build with >> dtraceall loaded (otherwise dtrace -G will fail I think). With that, >> the probes show up as expected. >> >> Do other ports create probes successfully? lang/php5 has a DTrace >> option and manages to create probes when I run it. If it doesn't in >> your environment, could you try running it with the >> DTRACE_DOF_INIT_DEBUG environment variable set to "1" and pass along >> the output? >> >> Thanks, >> -Mark > > Hi Mark, > As previous, adjusting the permissions on /dev/dtrace/helper resolved the issue. > What threw me was that I did try PHP & netatalk before posting & the > probes for those two did appear. > Revisiting those again now I see that they have a master process which > runs as root hence not being locked out of access to > /dev/dtrace/helper. > > Moving forward, what's your opinion on the adition of a new system > group called dtrace, & the devfs rules > > own dtrace/helper root:dtrace > perm dtrace/helper 0660 > > Postgresql can be made a member of this group if it's installed with > dtrace support & things work from the start. > Happy to raise the patch, just running it past you as I'm unsure what > ideas there are for delegating access in the future. I think it would be simpler to just allow any process to register probes through /dev/dtrace/helper, with some limits on the number of probes that can be registered by a given process. I believe this is what illumos does. If for some reason this can't be done, then having a dtrace group would be a good alternative, but it's probably preferable to avoid implementing both solutions. However, before changing the default permissions I'd like the code (probe and DOF registration handlers specifically) to be audited by someone on the security team. -Mark