In message <cac4bht7g4lje+fi4um539o-k_w7n7hbbpvd3zn4z0fw1ryl...@mail.gmail.com>
, Gordon Lang writes:
> 
> It works fine with BIND 9.9.3 but not 9.10.3 on the same server.

9.9.3 doesn't build threaded by default.
9.10.3 does build threaded by default.

Linux threads are a total mess as they are implemented as multiple
processes rather than actual threads of a single process.  This
means that syscalls that should apply to all threads don't and you
can't do things like change the uid of a program with multiple
threads active.

Additionally named isn't written as a suid executable.  It assumes
it is running as a ordinary user or as root (real, effective and
saved uid's are all zero) when starting.

It then temporarially changes uid several times, when running with
-u, to get the correct ownership and atomicity when creating files
and still have the right permissions when it needs them.

Mark

> 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=E2=80=99s capability mechanism to d=
> rop
> >       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).  =EF=BF=BC
> >
> >   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
> >
> >
> 
> --e89a8f83a3f94dc2e00520bf9f06
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> 
> <p dir=3D"ltr">It works fine with BIND 9.9.3 but not 9.10.3 on the same ser=
> ver.</p>
> <div class=3D"gmail_quote">On Sep 27, 2015 3:25 PM, &quot;Niall O&#39;Reill=
> y&quot; &lt;<a href=3D"mailto:niall.orei...@ucd.ie";>niall.orei...@ucd.ie</a=
> >&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" styl=
> e=3D"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>
> &gt;<br>
> &gt; Here is the file info:<br>
> &gt;<br>
> &gt; glang@nstv1:/export/local/ISC&gt; ls -ld bind-9.10.3/sbin<br>
> &gt; bind-9.10.3/sbin/named<br>
> &gt; drwxrwsr-x. 2 incadmin network 4096 Sep 26 10:39 bind-9.10.3/sbin<br>
> &gt; -rwsr-xr-x. 2 root network 10095219 Sep 26 09:16<br>
> &gt; bind-9.10.3/sbin/named<br>
> &gt; glang@nstv1:/export/local/ISC&gt;<br>
> &gt;<br>
> &gt; If I run &quot;named&quot; as user &#39;glang&#39; without the &quot;-=
> u&quot; option, it works<br>
> &gt; fine -- &quot;named&quot; runs as root (due to the suid file bit) and =
> it listens<br>
> &gt; on port 53 of the configured ip addresses.<br>
> <br>
> =C2=A0 Real user is unprivileged, but effective user is, so it all works.<b=
> r>
> <br>
> &gt; If I run &quot;named&quot; as user &#39;glang&#39; with the &quot;-u i=
> ncadmin&quot; option, it<br>
> &gt; does not work fine -- it runs with the change of process owner to<br>
> &gt; &#39;incadmin&#39;, but it does not listen on any ip addresses.<br>
> <br>
> =C2=A0 Real user is unprivileged. Effective user is briefly privileged,<br>
> =C2=A0 and later unprivileged.=C2=A0 In the section of the ARM which contai=
> ns<br>
> =C2=A0 copies of the man pages, I see the following description of the<br>
> =C2=A0 -u option.<br>
> <br>
> =C2=A0 =C2=A0 -u user<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 Setuid to user after completing privileged operations,=
>  such as<br>
> =C2=A0 =C2=A0 =C2=A0 creating sockets that listen on privileged ports.<br>
> <br>
> =C2=A0 =C2=A0 =C2=A0 NOTE<br>
> =C2=A0 =C2=A0 =C2=A0 On Linux, named uses the kernel=E2=80=99s capability m=
> echanism to drop<br>
> =C2=A0 =C2=A0 =C2=A0 all root privileges except the ability to bind(2) to a=
> <br>
> =C2=A0 =C2=A0 =C2=A0 privileged port and set process resource limits. Unfor=
> tunately,<br>
> =C2=A0 =C2=A0 =C2=A0 this means that the -u option only works when named is=
>  run on<br>
> =C2=A0 =C2=A0 =C2=A0 kernel 2.2.18 or later, or kernel 2.3.99-pre3 or later=
> , since<br>
> =C2=A0 =C2=A0 =C2=A0 previous kernels did not allow privileges to be retain=
> ed after<br>
> =C2=A0 =C2=A0 =C2=A0 setuid(2).=C2=A0 =EF=BF=BC<br>
> <br>
> =C2=A0 I don&#39;t doubt that you&#39;re running a new enough kernel.=C2=A0=
>  However, I<br>
> =C2=A0 guess that, since the real user didn&#39;t have the privileges in<br=
> >
> =C2=A0 question, the final effective user can&#39;t retain them.=C2=A0 With=
> out<br>
> =C2=A0 checking kernel and/or named code, I&#39;m afraid I can&#39;t do bet=
> ter then<br>
> =C2=A0 guess.<br>
> <br>
> &gt; If I run &quot;named&quot; as user &#39;root&#39; with the &quot;-u in=
> cadmin&quot; option, it<br>
> &gt; works fine -- it listens on the configured ip&#39;s and it changes the=
> <br>
> &gt; owner of the process to &#39;incadmin&#39;.<br>
> <br>
> =C2=A0 This is the &quot;traditional&quot; way to run a reduced-privilege i=
> nstance of<br>
> =C2=A0 named.=C2=A0 I&#39;ve used it, and I believe it&#39;s widely used.=
> =C2=A0 Are you sure<br>
> =C2=A0 it&#39;s not adequately secure for your needs?<br>
> <br>
> =C2=A0 Best regards,<br>
> =C2=A0 Niall O&#39;Reilly<br>
> <br>
> </blockquote></div>
> 
> --e89a8f83a3f94dc2e00520bf9f06--
> 
> --===============0301327172722298146==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> _______________________________________________
> 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
> --===============0301327172722298146==--
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
_______________________________________________
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

Reply via email to