Matthew Seaman writes:
> Furthermore, the default setup *is* for named to run as an unprivileged
> process. The setup is very carefully designed so that named doesn't
> have write permission on the directory where its configuration files are
> stored, or on directories that contain static zone fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/06/2010 09:37:03, krad wrote:
> so the logical extension to this is by changing the ownership of the
> directory to bind, you are making the configuration directory writeable, and
> therefore you are actually lowering security.
Correct.
On 17 June 2010 08:47, Matthew Seaman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 17/06/2010 04:21:34, Peter Boosten wrote:
> > On 17-6-2010 4:58, Robert Huff wrote:
> >>
> >> Martin McCormick writes:
> >>
> >>> Is there a way to keep /var/named owned by bind across
> >>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17/06/2010 04:21:34, Peter Boosten wrote:
> On 17-6-2010 4:58, Robert Huff wrote:
>>
>> Martin McCormick writes:
>>
>>> Is there a way to keep /var/named owned by bind across
>>> reboots?
>>
>> Yes. I had this happen for a long time.
>>
On 17-6-2010 4:58, Robert Huff wrote:
>
> Martin McCormick writes:
>
>> Is there a way to keep /var/named owned by bind across
>> reboots?
>
> Yes. I had this happen for a long time.
> The bad news is it had been years since I fixed it, and I no
> longer remember exactly what
Martin McCormick writes:
> Is there a way to keep /var/named owned by bind across
> reboots?
Yes. I had this happen for a long time.
The bad news is it had been years since I fixed it, and I no
longer remember exactly what I did. I will keep trying.
I run named chrooted to bind but not in a jail. When the
system reboots, something changes ownership of /var/named back
to root:wheel.
I have thought several times I figured out how to
prevent this from happening, but to no avail. The most promising
lead was the following directive