From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 12:50:49 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9A7106564A for ; Mon, 1 Sep 2008 12:50:49 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8DD798FC1D for ; Mon, 1 Sep 2008 12:50:49 +0000 (UTC) (envelope-from alex-goncharov@comcast.net) Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id 9PhM1a0090QuhwU51QaotD; Mon, 01 Sep 2008 12:34:48 +0000 Received: from daland.home ([24.61.21.4]) by OMTA02.westchester.pa.mail.comcast.net with comcast id 9Qal1a00E05H7zL3NQalB1; Mon, 01 Sep 2008 12:34:45 +0000 X-Authority-Analysis: v=1.0 c=1 a=WyKGbDgc-tgA:10 a=HHiX7DWWUSYA:10 a=rITDv7nW5hcA:10 a=p86Qp4d3rrSN5LiXVPkA:9 a=LY6ymqolsIcx-F8FWNcA:7 a=MUFzYB8CGC-18tBo0Wk_s5795eUA:4 a=si9q_4b84H0A:10 a=-ZQhYGXY2L8A:10 Received: from algo by daland.home with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Ka8cJ-000GgI-Um for freebsd-current@FreeBSD.org; Mon, 01 Sep 2008 08:34:47 -0400 From: Alex Goncharov To: freebsd-current@FreeBSD.org Message-Id: Sender: Alex Goncharov Date: Mon, 01 Sep 2008 08:34:47 -0400 Cc: Subject: named mystery -- error: dumping master file: master/tmp-wTjhUzoix6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Goncharov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2008 12:50:50 -0000 For quite a while I've been trying to understand how to work around this little annoyance: named periodically writes dumping master file: master/tmp-dnbiuWrKNQ: open: permission denied to `/var/log/message'. Sure, I thought -- out of the box the `master' directory doesn't give write permission to user bind: -------------------- $ pwd; ls -ld master /var/named/etc/namedb drwxr-xr-x 2 root wheel 512 Aug 17 13:47 master/ -------------------- If, in a default setup, I change the owner of `master' to `bind', a `named' restart will revert the ownership to `root', due to the settings in `/etc/mtree/BIND.chroot.dist'. So, a couple of months ago I changed the latter: ---------------------------------------- $ diff /etc/mtree/BIND.chroot.dist~ /etc/mtree/BIND.chroot.dist 14c14 < master --- > master uname=bind ---------------------------------------- After this change, every time I restart `named', the ownership of the `master' directory is changed to `bind' -- and this is what I want: user `bind', I would think, should be allowed to write to this directory. Every time after the restart everything is working well: no complains about the `master/tmp-XXX' files (which are zone dumps -- I did look at the code.) But also every time some time after the restart (perhaps a week or two down the road), something (and I can't figure out what), changes the owner of `master' to `root' -- and the zone dump gets impossible. Not that this leads to any problem in my DNS operations but I am totally flabbergasted about this behavior: looked at the code, did all kind of Internet searches and experiments, and still don't have an idea on: Who changes the owner of the `master' directory from `bind' to `root'? (The only thing I can think of is the dynamic DNS updates by DHCP daemon.) At this point, I pulled back my change to `/etc/mtree/BIND.chroot.dist' -- there is no use in it if somebody overrides my preference later, silently. Does anybody know what's going on? Who is that "silent changer"? What settings should I change to get things work right? Thanks, -- Alex -- alex-goncharov@comcast.net --