Date: Thu, 15 Jun 2017 07:16:33 -0700 From: Robert Mustacchi <rm@joyent.com> To: Matthew Seaman <matthew@FreeBSD.org>, freebsd-dtrace@freebsd.org Subject: Re: Creating a dtrace group? Message-ID: <8edf4d3d-625c-8a09-c541-61bc61f5f3d1@joyent.com> In-Reply-To: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org> References: <2909a957-80a9-8f14-079f-972d18143747@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/15/17 3:45 , Matthew Seaman wrote: > This is something that came up while I was flailing about trying to get > dtrace working with postgresql during BSDCan. Many thanks to markj and > swills and others for their help. > > By default the permissions/ownership on /dev/dtrace/helper look like this: > > crw-rw---- 1 root wheel 0x5 Jun 3 11:42 helper > > In order to dtrace a userland application it needs read/write access to > that device. Now, that's not the case for example with postgresql which > switches to a non-root uid on startup. Most persistent daemon processes > with network access will do this for obvious security reasons.> > The effect is that running 'dtrace -l -m postgres' shows no available > probes. > > One solution is to create a new 'dtrace' unix group, which the userids > those daemons run under can be added to, and make /dev/dtrace/helper > owned by that group. Like so: > > # pw group add -n dtrace -g 141 -M postgres > # cat /etc/devfs.rules > [userdtrace=10] > add path dtrace/helper mode 0660 group dtrace > # sysrc devfs_system_ruleset="userdtrace" > > (GID 141 is just the first available from /usr/ports/GIDs) This make > /dev/dtrace/helper look like so: > > crw-rw---- 1 root dtrace 0x5 Jun 3 11:42 helper > > and the postgres user account: > > # id postgres > uid=770(postgres) gid=770(postgres) groups=770(postgres),141(dtrace) > > Would it be possible to create a dtrace group like this in the default > /etc/group and change the devfs settings so that /dev/dtrace/helper is > group owned by the new dtrace by default? Preferably if this could go > into the upcoming 11.1 and 10.4 releases? Hi Matthew, Have you looked at the DTrace privilege model? If you haven't, it seems worth pointing out that DTrace has a notion of different privilege levels that are tied into different probes. Though this has never been ported over into FreeBSD. We use this a lot in illumos to solve problems like this. Importantly, for example, kernel probes require different privileges from USDT / pid probes. This means, for example, that destructive actions that can modify kernel memory can be taken away from things that just want to look at user land probes. In illumos, it also ties into privileges around what processes a user is allowed to see and modify (think what can I attach a debugger to), which helps from a notion of multi-tenancy. I'm not personally familiar with the FreeBSD privilege model, but seems like something you may want to think about, especially if this is coming up in the context of non-privileged users being used for security-conscious reasons. Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8edf4d3d-625c-8a09-c541-61bc61f5f3d1>