Bug with permissions of nsd.db / ixfr.db / ixfr.state?

NSD
1

Hi,

I'm running into an issue where the files nsd.db / ixfr.db / ixfr.state
are ending up being owned as root instead of nsd, which causes problems
later on when it is trying to update these files. I see this for instance
when running a nsdc rebuild (as root)

This happens without a "username" option, but also if I specify a
"username: nsd" option in the nsd config file.

Is there a reason why this is happening, or is this a bug?

I guess I can work around this by using the nsd uid to run update and
patch, but these run as root when using the initscripts, eg when using
"service nsd rebuild" and "service nsd patch", though I think that would
require the nsd account to have a valid login shell to use su, and
using sudo inherits some weird settings resulting (on RHEL) to get a
"mv: overwrite `/var/lib/nsdhm/nsd.db', overriding mode 0644?" message

Paul

2

Hi Paul,

Paul Wouters wrote:

Hi,

I'm running into an issue where the files nsd.db / ixfr.db / ixfr.state
are ending up being owned as root instead of nsd, which causes problems
later on when it is trying to update these files. I see this for instance
when running a nsdc rebuild (as root)

If you run as root, and do not provide a username, root will of course
get the ownership of these files.

This happens without a "username" option, but also if I specify a
"username: nsd" option in the nsd config file.

This may occur with nsdc rebuild, as the shell script does not take into
account the configfile. I think I need to add a chown for nsd.db.

However, this shouldn't occur for the ixfr.db and xfrd.state file. NSD
should have dropped permissions before writing these files and thus
create files as user 'nsd'.

Is there a reason why this is happening, or is this a bug?

As explained above.

Best regards,

Matthijs

3

I'm running into an issue where the files nsd.db / ixfr.db / ixfr.state
are ending up being owned as root instead of nsd, which causes problems
later on when it is trying to update these files. I see this for instance
when running a nsdc rebuild (as root)

If you run as root, and do not provide a username, root will of course
get the ownership of these files.

This happens without a "username" option, but also if I specify a
"username: nsd" option in the nsd config file.

This may occur with nsdc rebuild, as the shell script does not take into
account the configfile. I think I need to add a chown for nsd.db.

Yes.

And what is the case with nsd patch?

However, this shouldn't occur for the ixfr.db and xfrd.state file. NSD
should have dropped permissions before writing these files and thus
create files as user 'nsd'.

I'll let you know if I run into that again. Perhaps it was an error on
my part.

Paul