On 02/01/2012 01:52, Phil Mayers wrote:
> There's no need for the keyfile to be writeable by bind (at the moment,
> at any rate). So root:bind and 0640 seem more appropriate to me.
This makes more sense to me as well. Assume for the moment that an
attacker gains access as user bind. I really don't
>> Now the private key is inaccessible to the named process, which is
>> running as user bind. User bind is a member of group bind.
> Any time a private key file is rewritten, the mode is changed to 600.
> There's no rule that it has to be owned by root, though; could you just chown
> it to user
> > As is probably obvious, I consider it an irritating bug ;o)
>
> +1
Agreed. A warning that can be redirected to /dev/null might be okay.
Changing it unconditionally is not.
Steinar Haug, Nethelp consulting, sth...@nethelp.no
___
Please visit h
On 1 Feb 2012, at 09:52, Phil Mayers wrote:
> As is probably obvious, I consider it an irritating bug ;o)
+1
Niall O'Reilly
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users m
> I consider it a feature, though opinions may vary.
I consider it a bug, and it's going to bite hard.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
htt
On 02/01/2012 04:56 AM, Evan Hunt wrote:
Now the private key is inaccessible to the named process, which is
running as user bind. User bind is a member of group bind.
Any time a private key file is rewritten, the mode is changed to 600.
This kind of keyfile nannying annoys me, with other prod
> Now the private key is inaccessible to the named process, which is
> running as user bind. User bind is a member of group bind.
Any time a private key file is rewritten, the mode is changed to 600.
There's no rule that it has to be owned by root, though; could you just
chown it to user bind?
>
7 matches
Mail list logo
