Re: /var/named Changes Ownership to Root on Boot
In freebsd-questions Digest, Vol 207, Issue 18, Message: 6
On Fri, 21 Mar 2008 08:54:36 -0500
Martin McCormick [EMAIL PROTECTED] wrote:
I think I fixed it but I am not sure I would have
figured it out quickly without the help from the list.
It seems that FreeBSD defaults to a chroot of bind with
the tree owned by root. You can run bind in a sandbox as the
documentation says and have it chroot but if you do, and heres's
the confusion, you had better disable FreeBSD's attempt to make
sure the /var/named tree is always owned by root which would be
fine if named ran as root.
I'm sorry, but you seem a tad confused about how named operates in
sandbox mode. A thorough study of /etc/rc.d/named might help .. at
least, that's how I figured out how the whole chroot setup works.
As Chuck Swiger pointed out, quoted below, it's only necessary (and for
security, desirable) for the =subdirectories= of /var/named/var to be
owned bind:wheel, not /var/named, nor /var/named/etc with the exception
of a couple of directories. All this is setup (on each /etc/rc.d/named
start) by:
mtree -deU -f /etc/mtree/BIND.chroot.dist -p ${named_chrootdir}
where /etc/mtree/BIND.chroot.dist is, on my 5.5-STABLE(ish) system:
# $FreeBSD: src/etc/mtree/BIND.chroot.dist,v 1.5.2.2 2004/11/11 04:08:16
gshapiro Exp $
[..]
/set type=dir uname=root gname=wheel mode=0755
.
dev mode=0555
..
etc
namedb
dynamic uname=bind
..
master
..
slave uname=bind
..
..
..
/set type=dir uname=bind gname=wheel mode=0755
var uname=root
dump
..
log
..
run
named
..
..
stats
..
..
..
When you run it in a sandbox with a lower-priority UID,
you must make sure that at least one more little line appears in
rc.conf.local.
named_chrootdir= # Chroot directory (or not to auto-chroot it)
No, that STOPS named running in a chroot sandbox. Which is fine if you
want to run it the old (considered insecure) way; is that what you want?
That's the key right there. If you use lines from rc.conf.local
from an older system such as pre-FreeBSD5, you don't need that
line and things work fine. If you don't have it on a FreeBSD5 or
newer system,
/etc/defaults/rc.conf supplies the default version of that line
which reads:
named_chrootdir=/var/named # Chroot directory (or not to auto-chroot it)
That's right, and what you need to run it in the sandbox.
and one is seriously messed up from there on during the booting
process.
how 'messed up'? That's how it's supposed to work. You're supposed to
do bind configuration (/var/named/etc/namedb/named.conf etc) as root.
Ah, you might still have /etc/namedb as a directory, rather than a
symlink, if you'd done a source upgrade from 4.X to 5 or later? If so,
(save and) delete it and let /etc/rc.d/named make the symlink for you,
then move your config to /var/named/etc/namedb
I was confused and thought this would all help me keep
ownership of /var/named belonging to bind when, in fact, it does
just the opposite.
The whole point of the sandbox is to keep named, running as user bind,
from messing with anything out of its chroot environment if it were to
be compromised. The actual chroot is performed in run_rc_command() in
/etc/rc.subr if you want to see the gorier details.
Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Network Operations Group
Chuck Swiger writes:
/var/named is owned by root on all of my newer (5.x and later)
systems; I found an old 4.11 box with it owned by bind, though. If
you're using named chroot'ed (as recommended), it will want /var/named/
var/{dump/log/run/stats} writable by bind.
Yep, which is exactly what the mtree above does for you, every startup,
plus the dynamic and slave directories in (chrooted) /etc/namedb
The only problem I've struck with the chroot setup is a permission error
when trying to get debug (named.run) logging going, as named by default
wants to create the named.run file in the default directory (/etc/namedb
- /var/named/etc/namedb) which is of course owned by root, but I'm sure
I just need to spend a bit more time with the reference manual:
http://127.0.0.1/bind9ref/Bv9ARM.html
(where /usr/local/www/data/bind9ref - /usr/local/share/doc/bind9/arm/)
to find out how to get this log made in /var/log ie /var/named/var/log
- but I'll wait till I've upgraded to 6.3 before trying that again.
cheers, Ian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var/named Changes Ownership to Root on Boot
I think I fixed it but I am not sure I would have
figured it out quickly without the help from the list.
It seems that FreeBSD defaults to a chroot of bind with
the tree owned by root. You can run bind in a sandbox as the
documentation says and have it chroot but if you do, and heres's
the confusion, you had better disable FreeBSD's attempt to make
sure the /var/named tree is always owned by root which would be
fine if named ran as root.
When you run it in a sandbox with a lower-priority UID,
you must make sure that at least one more little line appears in
rc.conf.local.
named_chrootdir= # Chroot directory (or not to auto-chroot it)
That's the key right there. If you use lines from rc.conf.local
from an older system such as pre-FreeBSD5, you don't need that
line and things work fine. If you don't have it on a FreeBSD5 or
newer system,
/etc/defaults/rc.conf supplies the default version of that line
which reads:
named_chrootdir=/var/named# Chroot directory (or not to auto-chroot it)
and one is seriously messed up from there on during the booting
process.
I was confused and thought this would all help me keep
ownership of /var/named belonging to bind when, in fact, it does
just the opposite.
Martin McCormick WB5AGZ Stillwater, OK
Systems Engineer
OSU Information Technology Department Network Operations Group
Chuck Swiger writes:
/var/named is owned by root on all of my newer (5.x and later)
systems; I found an old 4.11 box with it owned by bind, though. If
you're using named chroot'ed (as recommended), it will want /var/named/
var/{dump/log/run/stats} writable by bind.
--
-Chuck
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var/named Changes Ownership to Root on Boot
At 08:54 AM 3/21/2008, Martin McCormick wrote: I think I fixed it but I am not sure I would have figured it out quickly without the help from the list. It seems that FreeBSD defaults to a chroot of bind with the tree owned by root. You can run bind in a sandbox as the documentation says and have it chroot but if you do, and heres's the confusion, you had better disable FreeBSD's attempt to make sure the /var/named tree is always owned by root which would be fine if named ran as root. When you run it in a sandbox with a lower-priority UID, you must make sure that at least one more little line appears in rc.conf.local. named_chrootdir= # Chroot directory (or not to auto-chroot it) That's the key right there. If you use lines from rc.conf.local from an older system such as pre-FreeBSD5, you don't need that line and things work fine. If you don't have it on a FreeBSD5 or newer system, /etc/defaults/rc.conf supplies the default version of that line which reads: named_chrootdir=/var/named# Chroot directory (or not to auto-chroot it) and one is seriously messed up from there on during the booting process. I was confused and thought this would all help me keep ownership of /var/named belonging to bind when, in fact, it does just the opposite. Yes it is confusing. It is more confusing if you upgrade as the chroot'ing behavior wasn't the default behavior in older versions. So often an upgraded system won't run named until you fix these settings. -Derek ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var/named Changes Ownership to Root on Boot
At 06:30 PM 3/20/2008, Martin McCormick wrote: About half of the 7 FreeBSD systems I run exhibit a very annoying behavior that I have not pinned down yet as to why and how to correct it. I reboot. Soon, I find that bind isn't running. It runs as a low-priority process and is owned by bind so it needs to have write permission in /var/named. When I do ls -ld on /var/named, it's owned by root. As I said, several systems do this and several more don't and they are all running FreeBSD6.2 except for one which is FreeBSD5.x. I originally used the stock /etc/rc.d start script for named. After getting the chown surprise on a key system, I hard-coded a 4-line script that just starts bind no matter what. It seemed to work so I was happy even though that is not a proper fix. After our master DHCP server played the chown prank on me yesterday, I added a fifth line to the hard-wire script to chown -R bind:bind /var/named. I guess the switcheroo happens after rc calls that script for I still had a dead bind until I changed it back and started it manually. Some other systems never do the switch and my test box, of course, is one of those so I can't fix what isn't broken. It seems like the boxes that do this are inversely proportional to their importance. Our master DNS did this to me this evening after a reboot so I am asking for an explanation of what I have done wrong to cause this to happen. I even did a sh -x /etc/rc/named and got kind of lost in rc.subr procedures and never saw the attempted switch of ownership. Thank you for any pointers to documentation that explains this as many of the systems in question are up for a year or more at times and we don't get to diagnose their boot process that often. When something fails to start, it's one of those SURPRISE!'s we'd all rather not have when in a hurry to get key systems back running again. Martin McCormick WB5AGZ Stillwater, OK Systems Engineer OSU Information Technology Department Network Operations Group Sounds like you have named chroot'ing and probably don't want that behavior. Look at the defaults for named and set them correctly in /etc/rc.conf -Derek -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var/named Changes Ownership to Root on Boot
On Mar 20, 2008, at 4:30 PM, Martin McCormick wrote:
I reboot. Soon, I find that bind isn't running. It runs
as a low-priority process and is owned by bind so it needs to
have write permission in /var/named. When I do ls -ld on
/var/named, it's owned by root.
/var/named is owned by root on all of my newer (5.x and later)
systems; I found an old 4.11 box with it owned by bind, though. If
you're using named chroot'ed (as recommended), it will want /var/named/
var/{dump/log/run/stats} writable by bind.
--
-Chuck
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: /var/named Changes Ownership to Root on Boot
Chuck Swiger writes:
/var/named is owned by root on all of my newer (5.x and later)
systems; I found an old 4.11 box with it owned by bind, though. If
you're using named chroot'ed (as recommended), it will want /var/named/
var/{dump/log/run/stats} writable by bind.
That's pretty much what I have. the log files and all
are in /var/named and everything works perfectly if I manually
reset the ownership back to bind for the entire tree starting at
/var/named.
I started seeing the behavior after FreeBSD5 and I did
in fact tell the configuration script of the bind port to chroot
since that is recommended. I thought that should tell the
process to assume the UID of bind and to chroot with /var/named
being the root directory.
Thanks to you and one other responder, I will have
another look at the defaults and see if there is anything I can
change. I seem to have unwittingly got some systems set up right
and others set up to chown root:wheel /var/named.
Martin McCormick
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
