cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 13

Anyone managing BIND with IPAM?

Jump to solution

Just curious if anyone out there is using this new feature.  If so, are you using a non-root user?

Tags (2)
1 Solution
Level 13

I just wanted to provide a follow up to this question, and for the issue that prompted the inquiry.

As part of the IPAM functionality, your user will login to the box and run 'named-checkconf -z -t "<directory to chroot>" <path to config>'.   By default, however, non-root users are not allowed to run chroot. As Support explained it:

As to the -t parameter, this is done from a management perspective to allow IPAM to send the config files on the machine into the temp location to prevent the need to overwrite the originals. This then allow it to perform a check to insure everything is ok if the config file is in the chroot directory. As the credential requirements designate it to have permissions for the service, the same applies in this regard to prevent the DNS from being negatively affected if something the application did affected the original config file.

So the issue is that you have to be root to run the named-checkconf as implemented in IPAM, but you don't want to have to use root to monitor BIND from IPAM. 

After working with Solarwinds support, they were able to provide me a workaround where we use setcap to add the 'cap_sys_chroot' capability to the named-checkconf utility, via the command 'setcap cap_sys_chroot+ep <path_to_named-checkconf>'.  This allows chroot to be called and the utility will function as needed. And of course, all of the other permissions outlined in the Tech Tip have to be correct as well.

Now, I'm no super linux security expert, but this seems to be a legit work around without giving away the key to the castle, as it were.  If there's a Linux person out there who knows why this might be an extraordinarily bad idea, please let us know.

Hope this helps someone else out there!

View solution in original post

0 Kudos
3 Replies
Level 13

I just wanted to provide a follow up to this question, and for the issue that prompted the inquiry.

As part of the IPAM functionality, your user will login to the box and run 'named-checkconf -z -t "<directory to chroot>" <path to config>'.   By default, however, non-root users are not allowed to run chroot. As Support explained it:

As to the -t parameter, this is done from a management perspective to allow IPAM to send the config files on the machine into the temp location to prevent the need to overwrite the originals. This then allow it to perform a check to insure everything is ok if the config file is in the chroot directory. As the credential requirements designate it to have permissions for the service, the same applies in this regard to prevent the DNS from being negatively affected if something the application did affected the original config file.

So the issue is that you have to be root to run the named-checkconf as implemented in IPAM, but you don't want to have to use root to monitor BIND from IPAM. 

After working with Solarwinds support, they were able to provide me a workaround where we use setcap to add the 'cap_sys_chroot' capability to the named-checkconf utility, via the command 'setcap cap_sys_chroot+ep <path_to_named-checkconf>'.  This allows chroot to be called and the utility will function as needed. And of course, all of the other permissions outlined in the Tech Tip have to be correct as well.

Now, I'm no super linux security expert, but this seems to be a legit work around without giving away the key to the castle, as it were.  If there's a Linux person out there who knows why this might be an extraordinarily bad idea, please let us know.

Hope this helps someone else out there!

View solution in original post

0 Kudos
Level 10

Hi Branfarm,

You can refer to this blog MANAGING BIND DNS SERVERS - WITHOUT CLI! it can help you with the feature.

-Ram

0 Kudos

Hey Ram,

Thanks for the response.  I'm actually trying to find out if anyone is able to get the feature working while using a non-root user. It works great when I tested it as root, but I've been having a heck of a time with it trying to use a different username. I have a support case open, so we'll see what happens.

0 Kudos