Question about dnstap

[Peter]

On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote:
! On 12. 09. 22 15:49, Peter wrote:
! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! > ! My testing did not uncover anything problematic.
! > !
! > ! Versions:
! > ! fstrm 0.6.1-1
! > ! protobuf 21.5-1
! > ! protobuf-c 1.4.1-1
! > !
! > !
! > ! A procedure which works:
! > ! - start BIND configured with
! > ! options {
! > ! 	dnstap { all; };
! > ! 	dnstap-output unix "/tmp/unix";
! > ! };
! > !
! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! > ! -w /tmp/capture
! > !
! > ! - fire couple queries: sleep 6 && dig bla example
! > !
! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature
! > 
! > Negative. Does not work here:
! > 
! > /tmp # ls -la capture
! > -rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
! > /tmp # dnstap-read -y /tmp/capture
! > /tmp # named -V
! > BIND 9.16.30 (Extended Support Version) <id:61fdb40>
! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
! 
! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are
! able to reproduce the problem you describe.

Okay, thank You for checking. I didn't look into the matter since I
got my things working nevertheless.
It looks a bit different now as not only me is experiencing the
behaviour.

! There is a caveat, though: Without the --split interval option one has to
! terminate fstrm_capture to get data for dnstap-read to consume. That's
! probably by design and outside of our control (in libfstrm).

This would then happen no matter if fstrm_capture is started before or
after named.


Let's have a short look.
truss tells me that named is trying to open the socket, and receives
ECONNREFUSED.
Then, after every 5 seconds (just as the docs say) it tries again, but
now it receives EPERM !

Apparently, the first connect() happens (after chroot but) before
droppings priviledges.
(The FreeBSD integration script does set -u to UID "bind", by default.)

So, apparently, fstrm_capture should also run as UID "bind" (and would
then need a proper filespace where it is allowed to create that
socket). Or something else along that line.

The OP should check if their problem suddenly resolves when doing a
"chmod 777" on that socket (and then devise a suitable design
according to their security policy).

It's a joy to work with you folks, as always. :)

-- PMc