Re: CVS commit: src/external/bsd/bind

[Christos Zoulas]

In article <20180214124743.40fe4f...@cvs.netbsd.org>,
Ryo ONODERA  wrote:
>-=-=-=-=-=-
>
>Module Name:   src
>Committed By:  ryoon
>Date:  Wed Feb 14 12:47:43 UTC 2018
>
>Modified Files:
>   src/external/bsd/bind: Makefile.inc
>
>Log Message:
>Fix broken dig and host commands
>
>OpenSSL 1.1 does not have GOST support, so restrict GOST support to 1.0.

Thanks!

christos

Re: CVS commit: src/external/bsd/bind/dist/lib/isc/include/isc

[Jukka Ruohonen]

On Wed, Sep 14, 2011 at 08:32:44AM +0100, David Laight wrote:
 On Tue, Sep 13, 2011 at 03:07:44PM -0400, Christos Zoulas wrote:
  Module Name:src
  Committed By:   christos
  Date:   Tue Sep 13 19:07:44 UTC 2011
  
  Modified Files:
  src/external/bsd/bind/dist/lib/isc/include/isc: util.h
  
  Log Message:
  Some versions of linux have probably marked fwrite(3) as
  __attribute__((__warn_unused_result__))
 
 What sort of moonshine are those guys on?
 
 Checking the result of fwrite() (and fprintf()) for error is often
 pointless since the error doesn't happen until the data is written.

While this case may be dubious, I think the __warn_unused_result__ attribute
is generally useful. It might even reveal a security bug one day. The lousy
practices of not checking return values were probably the reason for the
invention of exceptions and try {} catch {} -idioms, etc...

- Jukka.

Re: CVS commit: src/external/bsd/bind/dist/lib/isc/include/isc

[David Laight]

On Tue, Sep 13, 2011 at 03:07:44PM -0400, Christos Zoulas wrote:
 Module Name:  src
 Committed By: christos
 Date: Tue Sep 13 19:07:44 UTC 2011
 
 Modified Files:
   src/external/bsd/bind/dist/lib/isc/include/isc: util.h
 
 Log Message:
 Some versions of linux have probably marked fwrite(3) as
 __attribute__((__warn_unused_result__))

What sort of moonshine are those guys on?

Checking the result of fwrite() (and fprintf()) for error is often
pointless since the error doesn't happen until the data is written.
Unless the app always calls fflush() and ferror() before fclose()
checking the result from ferror/fprintf will only give a false
sense of security - and make the code unreadable.

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: src/external/bsd/bind

[Jeff Rizzo]

On 12/14/10 3:17 PM, Christos Zoulas wrote:

Module Name:src
Committed By:   christos
Date:   Tue Dec 14 23:17:21 UTC 2010

Modified Files:
src/external/bsd/bind: Makefile.inc

Log Message:
Handle NetBSD-5 and 4 lack of atomics by disabling threads.


To generate a diff of this commit:
cvs rdiff -u -r1.6 -r1.7 src/external/bsd/bind/Makefile.inc

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.


Shouldn't you be testing atomic.h from the target system rather than the 
host?


+.if exists(/usr/include/sys/atomic.h)

...seems wrong.

+j

re: CVS commit: src/external/bsd/bind/dist/bin/named

[matthew green]

   In article 22061.1240544...@splode.eterna.com.au,
   matthew green  m...@eterna.com.au wrote:
  
  Modified Files:
   src/external/bsd/bind/dist/bin/named: server.c
  
  Log Message:
  Don't log if . is not writable. In the chrooted environment this is
  /var/chroot/named, and there is no reason whatsoever for this to be
  writable!
   
   
   this seems bogus to me.
   
   this check seems to be about making sure it can write secondary
   files.  it's a good check.
   
   
   for my named chroot setup a9hich i've been using since before
   both netbsd or bind-proper had them, but using the same basic
   technique of named user/group  chroot), i kept named chdiring
   into, eg, /var/chroots/named/etc/namedb and that dir was
   writable, but the toplevel chroot dir was not.
   
   please restore this check and fix the usage.
   
   
   
   I don't think you are right here:
   
   $ ls -l /var/chroot/named/
   total 8
   drwxr-xr-x  2 root  wheel  512 Jun  3  2005 dev/
   drwxr-xr-x  4 root  wheel  512 Oct  2  2005 etc/
   drwxr-xr-x  3 root  wheel  512 May 22  2005 usr/
   drwxr-xr-x  4 root  wheel  512 May 22  2005 var/
   
   This is like root, and I have security issues changing the permissions there.
   Named has no business having write access there.

i'm not saying change this.
   
   Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?

i'm saying that named should be configured to have this dir as
the cwd and then the permissions check you removed will pass.

the bug here is that your named is running chrooted an unprived
in /var/chroot/named with cwd, not the etc/namedb subdir.
   

.mrg.

re: CVS commit: src/external/bsd/bind/dist/bin/named

[Christos Zoulas]

On Apr 25,  1:31am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/external/bsd/bind/dist/bin/named

|Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?
| 
| i'm saying that named should be configured to have this dir as
| the cwd and then the permissions check you removed will pass.

I take it that this dir means /var/chroot/named/etc/namedb, then perhaps
yes. I agree although not 100%, since my current tree looks like:

$ ls -al /var/chroot/named/etc/namedb
drwxr-xr-x  6 root   wheel   512 Jul 19  2008 ./
drwxr-xr-x  4 root   wheel   512 Jul 19  2008 ../
-rw-r--r--  1 root   wheel   259 Dec  3  2004 127
-r--r--r--  1 root   wheel  1525 May 30  2008 Makefile
drwxr-xr-x  2 root   wheel   512 Feb 15  2006 RCS/
drwxr-xr-x  2 named  named   512 Nov  4  2004 cache/
drwxr-xr-x  3 named  named   512 Apr 23  2007 pri/
-r--r--r--  1 root   wheel  2517 Nov  1  2007 root.cache
drwxr-xr-x  2 named  named  3584 Apr 24 11:40 sec/

[my primary zones are in pri and my secondary zones in sec]

And I don't really see the need to make the whole namedb directory owned
by named. Even the pri directory does not need to be writable by named.

| the bug here is that your named is running chrooted an unprived
| in /var/chroot/named with cwd, not the etc/namedb subdir.

Well, it needs to chroot there, but then it could chdir() to etc/namedb.
I will look if this is feasible when I get some cycles. For now commenting
out the test is the same behavior that we had in the previous versions
of named.

christos

Re: CVS commit: src/external/bsd/bind/dist/bin/named

[Perry E. Metzger]

chris...@zoulas.com (Christos Zoulas) writes:
 And I don't really see the need to make the whole namedb directory owned
 by named. Even the pri directory does not need to be writable by named.

The only time named really needs to write to the config dir is for
dynamic update. The only other time it writes is to dump a debugging
file -- the latter is supposed to be done in /var/tmp though.


Perry
-- 
Perry E. Metzgerpe...@piermont.com