On 26/6/2019 21:57, Tony Finch wrote: > Lefteris Tsintjelis via bind-users <bind-users@lists.isc.org> wrote: >> >> That makes perfect sense, but I was still shocked when I first saw it >> specially to a file owned by root. This is the part that surprised me >> and worried me the most! I was under the impression that after start up, >> named would switch to the user configured to do so and it will no longer >> be able to access or change other files but its' own. > > You are right about what named does, but you are also encountering > a classic UNIX gotcha, legitimately perplexing. > > See here, and click through the notes related answers to other questions: > https://unix.stackexchange.com/questions/75395/why-am-i-able-to-delete-file-which-belongs-to-root-under-a-non-root-user > > Also have a look at the description of the sticky bit in the chmod man page. > It makes directory permissions work more like you might expect.
If I set it though, and named no longer has access to modify and rewrite other files but its own, will it break things? What will happen in case of a dynamic update like ACME in this case? Will the update go through? Lefteris _______________________________________________ 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
