Re: named -u bind
-On [20010804 04:30], Jun Kuriyama ([EMAIL PROTECTED]) wrote: Are there any reasons not to use -u bind flag for named by default? Last time I discussed this with some people it was said that named will have a fit if you change the interface's IP address. It apparantly cannot accomodate for this change in rebinding. Going to a chrooted and non-root-running process is where I am going to, but I will test this first before I will commit this. And people, please remember that for now I am maintaining BIND, I will never see your emails if I am not reading these lists [the signal to noise ratio is so bad I hardly get around to weed through the STABLE and CURRENT lists. Thank god I do a fast subject check with `bind' to find things like this.] -- Jeroen Ruigrok van der Werven/Asmodai asmodai@[wxs.nl|freebsd.org|xmach.org] Documentation nutter/C-rated Coder, finger [EMAIL PROTECTED] http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/ A thousand times these mysteries unfold themselves like galaxies in my head... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
named -u bind
Are there any reasons not to use -u bind flag for named by default? # Or importing code to use chroot from OpenBSD? -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project bind.diff
Re: named -u bind
Jun Kuriyama [EMAIL PROTECTED] writes: At Fri, 03 Aug 2001 19:50:24 -0700, Dima Dorfman wrote: IIRC the last time this came up somebody said something about it not being able to read zonefiles in some odd places where they like to put them. I.e., they want it to run as root so they can set their zonefile mode 600 or something. If they are running on -stable, is it possible to change default behaviour on -current to use bind account? Don't ask me, I wasn't one of those people. *I* won't object to this change; I was just warning you that somebody might, for that reason. # Or importing code to use chroot from OpenBSD? Import code? BIND can run in a chroot just fine. Sorry for my poor explanation. This means to get a part of shell code in /etc/rc of OpenBSD to prepare chroot environment. This seems users can use chroot'ed named easily with only setting variables at /etc/rc.conf. This seems like a good idea whether it's the default or not. The only thing is that something running in a chroot should be built statically, unless you also want to stick libc and friends in there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: named -u bind
Date: Fri, 03 Aug 2001 19:50:24 -0700 From: Dima Dorfman [EMAIL PROTECTED] Are there any reasons not to use -u bind flag for named by default? IIRC the last time this came up somebody said something about it not being able to read zonefiles in some odd places where they like to put them. I.e., they want it to run as root so they can set their zonefile mode 600 or something. That sounds like someone overdoesed on perversity. I've been running named with user group bind (53) for nearly 2 years without significant problems: I made the directory named uses /var/namedb; everything in there is (still) owned by root, except for the sec subdirectory, which is owned by bind. (That is where the local copies of files retrieved from zone transfers go, for the zones for which my system is a slave. Having the named process unable to modify other files is a Good Thing. Oh, yeah: I also made /etc/named.conf a symlink to /var/namedb/named.conf.) I also made /var/run mode 1777, so that /var/run/named.pid could get created with minimal hassle. (Since the box has no general-purpose logins no keyboard, I have reasonable confidence that a local user isn't likely to abuse this.) Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
