[Bug 256849] [patch] dns/bind916: Support chrooting when used as samba4(13) DLZ backend

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256849

            Bug ID: 256849
           Summary: [patch] dns/bind916: Support chrooting when used as
                    samba4(13) DLZ backend
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: mat@FreeBSD.org
          Reporter: bugzilla.freebsd@omnilan.de
             Flags: maintainer-feedback?(mat@FreeBSD.org)
          Assignee: mat@FreeBSD.org

Created attachment 226063
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=226063&action=edit
Extend rc.d/named to handle chrooting samba4 DLZ dependencies

I noticed that running bind9 chrooted when loading samba's DLZ module wasn't
supported.
Although there's not too much of a security benefit considering the rest of the
jail binaries, for my environment, enclaving the DNS part seemd to be an easy
and beneficial step, since the FreeBSD bind9 port already makes chrooting an
easy to configure task.
Since I was unexpectedly happy with the outcome of my POC this week (using
Win10+RSAT to manage user accounts and DNS with jailed samba413 for a single
DomainController) I prepared this diff (tested on a FreeBSD 13 jail, only
providing kerberos/ldap/dns/rpc (by samba413), not serving any data besides
sysvol (GPO)).

It turned out that the dlz.so which samba provides needs a hallover lot of
other libraries and even pwd.db and other config files, so the diff is not as
small as I expected it to be at firsthand.

Please find it attched.
It extendends the chroot_autoupdate() function to copy all dependencies needed
to sucessfully run bind916 chrooted while still maintainable by RSAT via
samba413.

As long as you don't define named_chroot_dlzcopy
(="/usr/local/lib/samba4/modules/bind9/dlz_bind9_16.so" e.g.) in rc.conf,
there's no functional change.
If defined, and also set named_chroot, about 15MB libraries will be copied to
the chroot directory.

I haven't tested the non-jail (nullfs mount) part, but it's covered and I don't
expect problems.

For the records, here's the relevant part of my jail config to allow this patch
to do it's job:
winadc {
...
    # This must exactly match your 'named_chrootdir=' definition in
$path/etc/rc.conf!!
    $named_chrootdir = /enclave/named;
    mount += "devfs $path${named_chrootdir}/dev devfs rw 0 0";
    mount += "$path/var/db/samba4/bind-dns
$path${named_chrootdir}/var/db/samba4/bind-dns nullfs rw 0 0";
    mount += "$path/var/db/samba4/private/sam.ldb.d
$path${named_chrootdir}/var/db/samba4/private/sam.ldb.d nullfs rw 0 0";
    exec.created = "sh -c 'devfs_rulesets=\"/etc/defaults/devfs.rules
/etc/devfs.rules\"&& . /etc/rc.subr; devfs_init_rulesets && umount
$path${named_chrootdir}/dev 2>/dev/null && devfs_domount
$path${named_chrootdir}/dev devfsrules_hide_all && devfs -m
$path${named_chrootdir}/dev rule apply path null unhide && devfs -m
$path${named_chrootdir}/dev rule apply path random unhide && devfs -m
$path${named_chrootdir}/dev rule apply path crypto unhide || exit 1'";
...
}

The exec.created part is in use for DLZ/samba unrelated chrooted named(8) jail
setups too.

-- 
You are receiving this mail because:
You are the assignee for the bug.