From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 16 Oct 2003 - 01:45:13 BST
On Wed, Oct 15, 2003 at 09:28:05PM +0200, Dariush Pietrzak wrote:
>> For gawd's sake. Do not do that. Giving a vserver the
>> permission to take down the system, just so that you can
>> run a badly-compiled copy of Bind9, is
> In other words, nothing've changed, if you want to run
> bind9 your best bet is to run it chrooted on master server.
> (I prefer to run it chrooted as 'bind' user then to run
> it vserver-chrooted as 'root' ).
hmm, maybe all of you should have a look at the
source, to find that the following is true
(at least for 9.2.2)
named does (on linux only) change the capabilities
in such way, that a non root process can still bind
to reserved ports (< 1024), by calling capset, which
requires that ...
a) CAP_SETPCAP is present
b) requested capabilities are a subset of the
current capabilities ...
this is done with the following capabilities:
all capabilities (including CAP_SETPCAP) are
usually present in a vserver, except for the
CAP_SYS_RESOURCE, which, when granted, will allow
/* Override resource limits. Set resource limits. */
/* Override quota limits. */
/* Override reserved space on ext2 filesystem */
/* Modify data journaling mode on ext3 filesystem
(uses journaling resources) */
/* NOTE: ext2 honors fsuid when checking for resource
overrides, so you can override using fsuid too */
/* Override size restrictions on IPC message queues */
/* Allow more than 64hz interrupts from the real-time clock */
/* Override max number of consoles on console allocation */
/* Override max number of keymaps */
so, if this is okay for you, just add CAP_SYS_RESOURCE
to the capabilities for this vserver, if not, just
don't run bind9 at all, because it will require those
capability regardless of the environment (vserver or not ;)
please update FAQ/mind/whatever ...
Vserver mailing list