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