Hi Mark,
Dne 7.9.2018 v 10:49 Mark Elkins napsal(a):
> It would probably have been more helpful (speeded up finding the
> problem) if the error message "file 'named.secroots': permission denied"
> also gave the directory name that it was trying to write to? Just a thought.
> Sometimes we don't see the obvious.
It is sort of obvious, if you know the details. Bind changes current
directory to the directory listed in directory option. It actually tries
to open file path "named.secroots", in that directory. In that regard,
it is precise. It is documented, but not very obvious on the first
glance, what it really means.
>
>
> On 09/06/2018 10:58 PM, Brent Swingle wrote:
>> I moved the file from /etc to /var/named and now I get an additional error
>> line printed in /var/log/messages.
>>
>> Sep 6 15:44:40 ns3 named[15443]: received control channel command 'secroots'
>> Sep 6 15:44:40 ns3 named[15443]: could not open secroots dump file
>> 'named.secroots': permission denied
>> Sep 6 15:44:40 ns3 named[15443]: dumpsecroots failed: permission denied
>> Sep 6 15:44:40 ns3 audit: <audit-1400> { write } for pid=15447
>> comm="named" name="named.secroots" dev="dm-0" ino=135707451
>> scontext=system_u:system_r:named_t:s0
>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
>>
>>
>> This error also appears in the audit.log file and a search is pointing to
>> SELinux as the hangup. Any pointers on dealing with SELinux would be
>> appreciated.
>>
>> type=AVC msg=audit(1536266680.663:75671): avc: denied { write } for
>> pid=15447 comm="named" name="named.secroots" dev="dm-0" ino=135707451
>> scontext=system_u:system_r:named_t:s0
>> tcontext=unconfined_u:object_r:etc_t:s0 tclass=file permissive=0
>>
>>
>> I left all of the permissions the same and I think they should be lenient
>> enough:
>> [root@ns3 named]# ls -lh named.secroots
>> -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
>>
>>
>>
>>
>> -----Original Message-----
>> From: Hugo Salgado-Hernández [mailto:hsalg...@nic.cl]
>> Sent: Thursday, September 06, 2018 3:39 PM
>> To: Brent Swingle <br...@havilandtelco.com>
>> Cc: Evan Hunt <e...@isc.org>; bind-users@lists.isc.org
>> Subject: Re: [BIND] RE: KSK Rollover
>>
>> Hi Brent.
>> In out CentOS box, the named.secroots file is written on
>> /var/named/
>>
>> You should check permissions there too.
>>
>> Hugo
>>
>> On 20:32 06/09, Brent Swingle wrote:
>>> Evan,
>>>
>>> I ran the command and followed the directions to build out rndc as you have
>>> suggested. However, I am not sure that it made much of a difference. I
>>> should have been a little clearer from the beginning. I had worked with
>>> rndc to issue other commands and had received what appeared to be valid
>>> responses as if rndc was functional. I had somewhat assumed that rndc was
>>> baked in behind the scenes and ready to go. Either way I it has a
>>> rndc.conf and is specified in named.conf at this point.
>>>
>>> I have two of these servers that are identical from an SW perspective. As
>>> a test, I issued "rndc secroots" on the server that I have modified to
>>> configure rndc and observed the following lines appear in the
>>> /var/log/messages file. When I issued "rndc secroots" from the
>>> non-modified file I get the same 3 lines. It acts like the process is
>>> running but it is unable to write output to the named.secroots file.
>>>
>>> Sep 6 14:33:13 ns2 named[31189]: received control channel command
>>> 'secroots'
>>> Sep 6 14:33:13 ns2 named[31189]: could not open secroots dump file
>>> 'named.secroots': permission denied Sep 6 14:33:13 ns2 named[31189]:
>>> dumpsecroots failed: permission denied
>>>
>>>
>>> As a test, I manually created named.secroots with weakened permissions to
>>> see if that made a difference but it still won't print output to it.
>>> [root@ns3 etc]# ls -lh named.secroots
>>> -rw-rw-rw-. 1 named named 0 Sep 6 13:52 named.secroots
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Evan Hunt [mailto:e...@isc.org]
>>> Sent: Thursday, September 06, 2018 1:22 PM
>>> To: Brent Swingle <br...@havilandtelco.com>
>>> Cc: bind-users@lists.isc.org
>>> Subject: Re: KSK Rollover
>>>
>>> On Thu, Sep 06, 2018 at 05:34:21PM +0000, Brent Swingle wrote:
>>>> This is the command that does not work and the output received:
>>>> [root@ns2 ~]# rndc secroots
>>>> rndc: 'secroots' failed: permission denied
>>>> [root@ns2 ~]#
>>> Have you set up your server to accept rndc commands?
>>>
>>> If not, run "rndc-confgen" and follow the directions.
>>>
>>> --
>>> Evan Hunt -- e...@isc.org
>>> Internet Systems Consortium, Inc.
>>>
>>> _______________________________________________
>>> 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
>>>
>> _______________________________________________
>> 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
>
--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com PGP: 65C6C973
_______________________________________________
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
