[Bug 223025] dns/bind910: issues with syslogd when running chrooted

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 223025
           Summary: dns/bind910: issues with syslogd when running chrooted
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: mat at FreeBSD.org
          Reporter: fletch-devel+freebsd at rtfm.net.au
          Assignee: mat at FreeBSD.org
             Flags: maintainer-feedback?(mat at FreeBSD.org)

Hi.

I am running bind910 on FreeBSD 11.1.

When running named chrooted, if syslogd stops for some reason, when syslogd is
restarted, named does not resume logging.

My guess for this is that the file descriptor for the /var/run/log socket is
opened by named before dropping privileges and doing a chroot. So when syslogd
stops, I assume named regularly checks for the existence of the socket
/var/run/log, but cannot because it is running chrooted.

The obvious way around this is to make sure syslogd creates an additional
socket file in the /var/run/log directory UNDER the chroot path (eg.
/usr/local/var/named/var/run/log).

Unfortunately, this needs to be done with the /etc/rc.conf variable:
syslogd_flags (eg. syslogd_flags="-l /usr/local/var/named/var/run/log"), so the
named script in /usr/local/etc/rc.d/ cannot do it for us.

In my opinion, some sort of warning could be added to the named rc script when
chrooting is requested, but the socket file cannot be found in the chroot
filespace.

This would be an easy modification and could be important for security for
those who overlook this possibility and restart syslogd for some reason. On a
critical system that runs for a long time, this could be a very bad thing if
their logging disappears.

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