Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-28 Thread Doug Barton

On 4/27/19 9:22 PM, Tim Daneliuk wrote:

On 4/27/19 5:33 PM, @lbutlr wrote:

On 27 Apr 2019, at 16:21, Tim Daneliuk  wrote:

Why is 9.12+ now suddenly so grumpy about who owns the files?  Is this a recent 
fix to reduce the attack surface on files owned by root?


Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I 
can't find it.




Possibly relevant:


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


Yes, that's almost certainly it. Sad to see that the FreeBSD ports team 
is still doing their usual stellar job of "It's not our problem."


You need to make the directory you define as the working directory 
("directory" in named.conf) writable to the named process.


I vaguely recall that I might have had code to make sure that got set 
correctly in the rc.conf file back when I was maintaining the BIND 
ports, but I can't figure out what they've done to the repo, and I can't 
find my old stuff in there.


You're probably better off making your working directory something 
that's not named in the mtree file, so that your permissions don't get 
"fixed" by it.


hope this helps,

Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-27 Thread Tim Daneliuk
On 4/27/19 5:33 PM, @lbutlr wrote:
> On 27 Apr 2019, at 16:21, Tim Daneliuk  wrote:
>> Why is 9.12+ now suddenly so grumpy about who owns the files?  Is this a 
>> recent fix to reduce the attack surface on files owned by root?
> 
> Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I 
> can't find it.
> 
> 

Possibly relevant:


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

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-27 Thread @lbutlr
On 27 Apr 2019, at 16:21, Tim Daneliuk  wrote:
> Why is 9.12+ now suddenly so grumpy about who owns the files?  Is this a 
> recent fix to reduce the attack surface on files owned by root?

Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I 
can't find it.


-- 
One of the most basic rules of survival on any planet is never to upset
someone wearing black leather. --The Last Continent


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-27 Thread Tim Daneliuk
On 4/27/19 3:33 PM, Anand Buddhdev wrote:
> On 27/04/2019 21:52, Tim Daneliuk wrote:
> 
> Hi Tim,
> 
>> Running:  FreeBSD 11.2-STABLE #0 r345904
>>
>> Bind 9.11 works fine.  If I attempt to install 9.12 or greater, the
>> installation succeeds but any attempt to start the daemon fails silently.
>> Output of 'sh -x /usr/local/rc.d/named start' follows below.
> 
> This doesn't show anything useful. BIND usually logs to syslog when
> starting up. Check your syslog - you may find more useful messages in there.
> 
> Regards,
> Anand
> 

D'oh ... I didn't even think of that (and I should have).

It appears to have been a file ownership problem with some files in
/usr/local/etc/named ... but it's weird.  First of all, all files in there
were group and world readable.  Why is 9.12+ now suddenly so grumpy about
who owns the files?  Is this a recent fix to reduce the attack surface
on files owned by root?

-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-27 Thread Anand Buddhdev
On 27/04/2019 21:52, Tim Daneliuk wrote:

Hi Tim,

> Running:  FreeBSD 11.2-STABLE #0 r345904
> 
> Bind 9.11 works fine.  If I attempt to install 9.12 or greater, the
> installation succeeds but any attempt to start the daemon fails silently.
> Output of 'sh -x /usr/local/rc.d/named start' follows below.

This doesn't show anything useful. BIND usually logs to syslog when
starting up. Check your syslog - you may find more useful messages in there.

Regards,
Anand
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Bind > 9.12 Will Not Start On FreeBSD

2019-04-27 Thread Tim Daneliuk
Running:  FreeBSD 11.2-STABLE #0 r345904

Bind 9.11 works fine.  If I attempt to install 9.12 or greater, the
installation succeeds but any attempt to start the daemon fails silently.
Output of 'sh -x /usr/local/rc.d/named start' follows below.

Any thoughts or pointers would be deeply appreciated...


Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/



+ named_enable=YES
+ named_program=/usr/local/sbin/named
+ named_conf=/usr/local/etc/namedb/named.conf
+ named_flags=''
+ named_uid=bind
+ named_chrootdir=''
+ named_chroot_autoupdate=YES
+ named_symlink_enable=YES
+ named_wait=NO
+ named_wait_host=localhost
+ named_auto_forward=NO
+ named_auto_forward_only=NO
+ required_dirs=''
+ _named_confdirroot=/usr/local/etc/namedb
+ _named_confdir=/usr/local/etc/namedb
+ _named_program_root=/usr/local
+ _openssl_engines=/usr/lib/engines
+ rndc_conf=/usr/local/etc/namedb/rndc.conf
+ rndc_key=/usr/local/etc/namedb/rndc.key
+ run_rc_command start
+ _return=0
+ rc_arg=start
+ [ -z named ]
+ shift 1
+ rc_extra_args=''
+ _rc_prefix=''
+ eval '_override_command=$named_program'
+ _override_command=/usr/local/sbin/named
+ command=/usr/local/sbin/named
+ _keywords='start stop restart rcvar enabled describe extracommands reload'
+ rc_pid=''
+ _pidcmd=''
+ _procname=/usr/local/sbin/named
+ [ -n /usr/local/sbin/named ]
+ [ -n '' ]
+ _pidcmd='rc_pid=$(check_process /usr/local/sbin/named )'
+ _keywords='start stop restart rcvar enabled describe extracommands reload 
status poll'
+ [ -z start ]
+ [ start '=' enabled ]
+ [ -n '' ]
+ eval 'rc_flags=$named_flags'
+ rc_flags=''
+ eval '_chdir=$named_chdir' '_chroot=$named_chroot' '_nice=$named_nice' 
'_user=$named_user' '_group=$named_group' '_groups=$named_groups' 
'_fib=$named_fib' '_env=$named_env' '_prepend=$named_prepend' 
'_login_class=${named_login_class:-daemon}' '_oomprotect=$named_oomprotect'
+ _chdir='' _chroot='' _nice='' _user='' _group='' _groups='' _fib='' _env='' 
_prepend='' _login_class=daemon _oomprotect=''
+ [ -n '' ]
+ [ -z '' ]
+ eval 'rc_pid=$(check_process' /usr/local/sbin/named ')'
+ check_process /usr/local/sbin/named
+ _procname=/usr/local/sbin/named
+ _interpreter=''
+ [ -z /usr/local/sbin/named ]
+ _find_processes /usr/local/sbin/named . -ax
+ [ 3 -ne 3 ]
+ _procname=/usr/local/sbin/named
+ _interpreter=.
+ _psargs=-ax
+ _pref=''
+ [ . '!=' . ]
+ _procnamebn=named
+ _fp_args='_arg0 _argv'
+ _fp_match=$'case "$_arg0" in
\t\t
$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")'
+ _proccheck=$'\t\t/bin/ps -ww 2>/dev/null -o pid= -o jid= -o command= -ax |
\t\twhile read _npid _jid _arg0 _argv; do
\t\t\tcase "$_arg0" in
\t\t
$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")
\t\t\t\tif [ "$JID" -eq "$_jid" ];
\t\t\t\tthen echo -n "$_pref$_npid";
\t\t\t\t_pref=" ";
\t\t\t\tfi
\t\t\t\t;;
\t\t\tesac
\t\tdone'
+ eval /bin/ps -ww '2>/dev/null' -o 'pid=' -o 'jid=' -o 'command=' -ax '|' 
while read _npid _jid _arg0 '_argv;' do case '"$_arg0"' in 
'$_procname|$_procnamebn|${_procnamebn}:|"(${_procnamebn})"|"[${_procnamebn}]")'
 if [ '"$JID"' -eq '"$_jid"' '];' then echo -n '"$_pref$_npid";' '_pref="' '";' 
fi ';;' esac done
+ /bin/ps -ww -o 'pid=' -o 'jid=' -o 'command=' -ax
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv
+ read _npid _jid _arg0 _argv