/var/lib/named not writable by named?

[Josef Moellers]

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

Josef
-- 
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany

(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer