hi,
as i wrote earlier there is a few confusion around file permissions and
euid with nsd. i try to find anything about it but can't find the vaild
doc. nsd run as user nsd (by defult), so create files as nsd. a few
notes which would be useful to include in the readme:
- /etc/nsd should have to owned by nsd (otherwise can't update zones:
could not open file /etc/nsd/ixfr.db for append: Permission denied)
- files in the /etc/nsd would be useful to owned by nsd.
on the other hand
- nsdc, nsd-patch and nsd-xfer should have to run as the configured user
(nsd by default) so the generated db, zone and transfer files owned by
nsd. in this case file permission would be consistent. now eg. ixfr.db
owned by nsd while nsd.db owned by root. master zone files owned by nsd
slaves owned by root (nsd-patch generated, yes i know cron can be run as
a given user, but). if you assume you can write a perfect code nsd can
run as root, if try to be safe run all tools as nsd.
hi,
as i wrote earlier there is a few confusion around file permissions and
euid with nsd. i try to find anything about it but can't find the vaild
doc. nsd run as user nsd (by defult), so create files as nsd. a few
notes which would be useful to include in the readme:
- /etc/nsd should have to owned by nsd (otherwise can't update zones:
could not open file /etc/nsd/ixfr.db for append: Permission denied)
- files in the /etc/nsd would be useful to owned by nsd.
I also noticed this -- there are some bootstrapping issues when a new
installation is started. Partly, this can be solved by smart things in
"make install" but that won't solve reconfiguration, which is why there
needs to be documentation as well.
I'd suggest that the config sample files get text along these lines.
on the other hand
- nsdc, nsd-patch and nsd-xfer should have to run as the configured user
(nsd by default) so the generated db, zone and transfer files owned by
nsd. in this case file permission would be consistent. now eg. ixfr.db
owned by nsd while nsd.db owned by root. master zone files owned by nsd
slaves owned by root (nsd-patch generated, yes i know cron can be run as
a given user, but). if you assume you can write a perfect code nsd can
run as root, if try to be safe run all tools as nsd.
Setuid shell scripts are generally complicated. Running the binaries inside
a shell script with "su" and the main script as root is doable.
i forget to mention that the spec file attached to my previous mail can
be used to create rpm for nsd (based on the fedora extras spec file and
updated to 3.0.3 and a few permission is modofied).
on the other hand
- nsdc, nsd-patch and nsd-xfer should have to run as the configured user
(nsd by default) so the generated db, zone and transfer files owned by
nsd. in this case file permission would be consistent. now eg. ixfr.db
owned by nsd while nsd.db owned by root. master zone files owned by nsd
slaves owned by root (nsd-patch generated, yes i know cron can be run as
a given user, but). if you assume you can write a perfect code nsd can
run as root, if try to be safe run all tools as nsd.
Setuid shell scripts are generally complicated. Running the binaries inside
a shell script with "su" and the main script as root is doable.
nsdc shell script can run as root, but zonec, nsd-patch, nsd-xfer etc.
can change euid to nsd and it'd be enough.
i forget to mention that the spec file attached to my previous mail can
be used to create rpm for nsd (based on the fedora extras spec file and
updated to 3.0.3 and a few permission is modofied).
Hmm, nice for contrib? Thanks.
<snip UID discussion>
Not sure about what to do about it right now. Can it be that other
operators want a different UID because of their setup?
Farkas Levente wrote:
i've got such an error message too:
-----------------------
Dec 11 04:02:46 ns1 nsd[14372]: could not read /etc/nsd/nsd.db CRC. db
changed?
-----------------------
i don't know it's permission related or not, but strange.
just my 2c.
Thank you. I have changed the error message. It is now only printed when
an error happens (not on EOF, or some thing like that), and includes the
system errno. In the next release you should not see it, or it should
say something interesting.
i forget to mention that the spec file attached to my previous mail can
be used to create rpm for nsd (based on the fedora extras spec file and
updated to 3.0.3 and a few permission is modofied).
Hmm, nice for contrib? Thanks.
would be better to put into the top level dir since in this case:
rpmbuild -ta nsd-3.0.3.tar.gz
will build the rpm (it's only working if the spec file is in the top
level dir of the archive).
<snip UID discussion>
Not sure about what to do about it right now. Can it be that other
operators want a different UID because of their setup?
couldn't the other binary also change uid the same way as nsd do?