<p dir="ltr">It works fine with BIND 9.9.3 but not 9.10.3 on the same server.</p>
<div class="gmail_quote">On Sep 27, 2015 3:25 PM, "Niall O'Reilly" <<a href="mailto:niall.oreilly@ucd.ie">niall.oreilly@ucd.ie</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 27 Sep 2015 16:59:14 +0100,<br>
Gordon Lang wrote:<br>
><br>
> Here is the file info:<br>
><br>
> glang@nstv1:/export/local/ISC> ls -ld bind-9.10.3/sbin<br>
> bind-9.10.3/sbin/named<br>
> drwxrwsr-x. 2 incadmin network 4096 Sep 26 10:39 bind-9.10.3/sbin<br>
> -rwsr-xr-x. 2 root network 10095219 Sep 26 09:16<br>
> bind-9.10.3/sbin/named<br>
> glang@nstv1:/export/local/ISC><br>
><br>
> If I run "named" as user 'glang' without the "-u" option, it works<br>
> fine -- "named" runs as root (due to the suid file bit) and it listens<br>
> on port 53 of the configured ip addresses.<br>
<br>
  Real user is unprivileged, but effective user is, so it all works.<br>
<br>
> If I run "named" as user 'glang' with the "-u incadmin" option, it<br>
> does not work fine -- it runs with the change of process owner to<br>
> 'incadmin', but it does not listen on any ip addresses.<br>
<br>
  Real user is unprivileged. Effective user is briefly privileged,<br>
  and later unprivileged.  In the section of the ARM which contains<br>
  copies of the man pages, I see the following description of the<br>
  -u option.<br>
<br>
    -u user<br>
<br>
      Setuid to user after completing privileged operations, such as<br>
      creating sockets that listen on privileged ports.<br>
<br>
      NOTE<br>
      On Linux, named uses the kernel’s capability mechanism to drop<br>
      all root privileges except the ability to bind(2) to a<br>
      privileged port and set process resource limits. Unfortunately,<br>
      this means that the -u option only works when named is run on<br>
      kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later, since<br>
      previous kernels did not allow privileges to be retained after<br>
      setuid(2).  <br>
<br>
  I don't doubt that you're running a new enough kernel.  However, I<br>
  guess that, since the real user didn't have the privileges in<br>
  question, the final effective user can't retain them.  Without<br>
  checking kernel and/or named code, I'm afraid I can't do better then<br>
  guess.<br>
<br>
> If I run "named" as user 'root' with the "-u incadmin" option, it<br>
> works fine -- it listens on the configured ip's and it changes the<br>
> owner of the process to 'incadmin'.<br>
<br>
  This is the "traditional" way to run a reduced-privilege instance of<br>
  named.  I've used it, and I believe it's widely used.  Are you sure<br>
  it's not adequately secure for your needs?<br>
<br>
  Best regards,<br>
  Niall O'Reilly<br>
<br>
</blockquote></div>