/var/lib/named not writable by named?
jmoellers at suse.de
Fri Jul 24 06:57:55 UTC 2020
On 23.07.20 23:38, Jeremy C. Reed wrote:
> On Thu, 23 Jul 2020, Josef Moellers wrote:
>> I do understand about dropping privileges, which is perfectly OK. Named
>> runs as user/group named/named and so has no special privileges, but we
>> had an issue recently wrt transactional updates and we solved it by
>> making /var/lib/named owner root:named and perms rwxrwxr-t which would
>> allow write access only to root and named. I am weary about any security
>> issues which may arise from this. That's why I'm asking.
> You will need to explain or show "issue recently wrt transactional
> updates". (If this was me, I would collect the error messages if any,
> enable some debugging, use ktrace or equivalent to help understand it.)
As I wrote, the policy enforced by systemd-tmpfiles forbids a directory
owned yb root in a parent directory owned by a non-privileged user, so
/var/lib/named is owned by named:named and
/var/lib/named/dev (required for the chrooted named) is owned by root:root
systemd-tmpfiles says this is a nono and thus refuses to build the
subtree effectively preventing named to run in the chroot jail.
> I run BIND frequently without root privileges -- including starting it
> up (as non-root) and using it extensively as non-root (tens of thousands
> of separate uses).
Yepp: never run a program with elevated privileges if it can also run
with normal privileges
SUSE Software Solutions Germany GmbH
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
More information about the bind-workers