Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #208658 > unrolled thread

bind gets permission errors in buster--systemd-related?

Back to article view | Back to linux.debian.user

Contents

  bind gets permission errors in buster--systemd-related? Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-15 07:10 +0200
    Re: bind gets permission errors in buster--systemd-related? Sven Joachim <svenjoac@gmx.de> - 2019-05-15 18:00 +0200
      Re: bind gets permission errors in buster--systemd-related? Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-15 19:00 +0200
        Re: bind gets permission errors in buster--systemd-related? Sven Joachim <svenjoac@gmx.de> - 2019-05-15 19:40 +0200
          Re: bind gets permission errors in buster--systemd-related? Ross Boylan <rossboylan@stanfordalumni.org> - 2019-05-15 20:30 +0200
    Re: bind gets permission errors in buster--systemd-related? Lee <ler762@gmail.com> - 2019-05-15 18:40 +0200
      Re: bind gets permission errors in buster--systemd-related? Greg Wooledge <wooledg@eeg.ccf.org> - 2019-05-15 19:10 +0200
    Re: bind gets permission errors in buster--systemd-related? Bob Weber <bobrweber@gmail.com> - 2019-05-15 20:30 +0200

#208658 — bind gets permission errors in buster--systemd-related?

I have a new buster system with a bind setup based on (much) older*
systems, on which it worked fine.  On buster, it doesn't.
In two different places in my configuration I referred to files or
directories that were outside of bind proper, and in both cases this
failed with permission problems.
I'm pretty sure bind is running under systemd, and have seen various
references to systemd limiting access to the file system.  However, I
don't see anything that appears to be requesting such limits for
bind9, or in general.  /var is a different partition from /, and I
configured bind to run as an ordinary user.

Any ideas what's going on, or what I can do to fix it?

        // RB modified resolv.conf with custom
/etc/resolvconf/update.d/bind9 to create this file.
    //include "/run/named/named.resolvers";
    /* Error was
May 11 12:46:27 barley named[15935]: loading configuration from
'/etc/bind/named.conf'
May 11 12:46:27 barley named[15935]: /etc/bind/named.conf.options:18:
open: /run/named/named.resolvers: permission denied
May 11 12:46:27 barley named[15935]: loading configuration: permission denied
May 11 12:46:27 barley named[15935]: exiting (due to fatal error)

The script clearly starts as the bind user, and when I su to bind I
can cat the file.
*/

Second,  I had a bunch of logging directives like
logging {
/*  permission problems opening the log files.  Not sure why.
  channel update_debug{
    file "/var/log/bind/dnsupdate.log";
    severity  debug 3;
    print-category yes;
    print-severity yes;
    print-time yes;
    };
*/
/var/log/bind is owned by bind.

For now I just commented the problems out, but I'd like it to work.
For one thing, my network configuration is not static.

Thanks.
Ross

*Specifically bind9 (1:9.8.4.dfsg.P1-6+nmu2+deb7u20) wheezy-security

[toc] | [next] | [standalone]

#208672

On 2019-05-14 21:50 -0700, Ross Boylan wrote:

> I have a new buster system with a bind setup based on (much) older*
> systems, on which it worked fine.  On buster, it doesn't.
> In two different places in my configuration I referred to files or
> directories that were outside of bind proper, and in both cases this
> failed with permission problems.
> I'm pretty sure bind is running under systemd, and have seen various
> references to systemd limiting access to the file system.  However, I
> don't see anything that appears to be requesting such limits for
> bind9, or in general.  /var is a different partition from /, and I
> configured bind to run as an ordinary user.
>
> Any ideas what's going on, or what I can do to fix it?

Most likely this has nothing to do with systemd, rather it's apparmor
which denies access to /run/named/named.resolvers.

>         // RB modified resolv.conf with custom
> /etc/resolvconf/update.d/bind9 to create this file.
>     //include "/run/named/named.resolvers";
>     /* Error was
> May 11 12:46:27 barley named[15935]: loading configuration from
> '/etc/bind/named.conf'
> May 11 12:46:27 barley named[15935]: /etc/bind/named.conf.options:18:
> open: /run/named/named.resolvers: permission denied

The question is why your /etc/bind/named.conf.options file tries to open
/run/named/named.resolvers.  Certainly this is not done by default, and
you probably want to fix that.

Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#208675

Sven, thanks for the tip about AppArmor.  Yet another presumably
complicated system I've avoided learning about til now.  I guess it's
time.

As to why bind is trying to open /run/named/named.resolvers: that is a
customized integration with resolvconf.  It is not the default, but it
is something I want to work.  Or I need an alternate way to achieve
the same functionality, which is that when resolvconf gets info on
nameservers it passes that on to bind.

Lee, I don't think this is a vanilla permission problem.  As I thought
the comments in the original indicated, ownership and permissions look
as if they should be good for the bind user, and I even su'd to bind
and was able to access one of the files that the bind daemon said it
couldn't access.

Ross

[toc] | [prev] | [next] | [standalone]

#208677

On 2019-05-15 09:33 -0700, Ross Boylan wrote:

> Sven, thanks for the tip about AppArmor.  Yet another presumably
> complicated system I've avoided learning about til now.  I guess it's
> time.
>
> As to why bind is trying to open /run/named/named.resolvers: that is a
> customized integration with resolvconf.  It is not the default, but it
> is something I want to work.  Or I need an alternate way to achieve
> the same functionality, which is that when resolvconf gets info on
> nameservers it passes that on to bind.

I am not really familiar with apparmor or resolvconf, but in
/etc/apparmor.d/usr.sbin.named I found the following:

,----
|   # support for resolvconf
|   /{,var/}run/named/named.options r,
`----

which suggests that the standard way would be to use
/run/named/named.options rather than /run/named/named.resolvers.
Alternatively, you may put the following line into
/etc/apparmor.d/local/usr.sbin.named:

  /{,var/}run/named/named.resolvers r,


Cheers,
       Sven

[toc] | [prev] | [next] | [standalone]

#208680

On Wed, May 15, 2019 at 10:39 AM Sven Joachim <svenjoac@gmx.de> wrote:
....
> I am not really familiar with apparmor or resolvconf, but in
> /etc/apparmor.d/usr.sbin.named I found the following:
>
> ,----
> |   # support for resolvconf
> |   /{,var/}run/named/named.options r,
> `----
>
> which suggests that the standard way would be to use
> /run/named/named.options rather than /run/named/named.resolvers.
> Alternatively, you may put the following line into
> /etc/apparmor.d/local/usr.sbin.named:
>
>   /{,var/}run/named/named.resolvers r,

Yep.  Not only that, but just below that is
  # some people like to put logs in /var/log/named/ instead of having
  # syslog do the heavy lifting.
  /var/log/named/** rw,
  /var/log/named/ rw,
so if I switch my logs to there (and rename the directory), instead of
/var/log/bind,
 the logging should work too.  Or I could add apparmor entries for
/var/log/bind.

I'm still trying to figure out what, if anything, is necessary for
revised apparmor settings to take effect.

Thanks.

[toc] | [prev] | [next] | [standalone]

#208674

On 5/15/19, Ross Boylan <rossboylan@stanfordalumni.org> wrote:
> I have a new buster system with a bind setup based on (much) older*
> systems, on which it worked fine.  On buster, it doesn't.
> In two different places in my configuration I referred to files or
> directories that were outside of bind proper, and in both cases this
> failed with permission problems.
> I'm pretty sure bind is running under systemd, and have seen various
> references to systemd limiting access to the file system.  However, I
> don't see anything that appears to be requesting such limits for
> bind9, or in general.  /var is a different partition from /, and I
> configured bind to run as an ordinary user.
>
> Any ideas what's going on, or what I can do to fix it?

You're not showing file or directory permissions, so it's hard to guess.
The way I fixed my permission problems after telling bind to log to a
file instead of syslog was
  su -
to become root
  su bind
which didn't work because
  # grep bind /etc/passwd
  bind:x:116:119::/var/cache/bind:/bin/false
so edit /etc/passwd and change '/bin/false' to '/bin/sh'
  su bind
then worked, so
  /usr/sbin/named -g
to see all the errors.  Adjust permissions, start bind as a daemon and
edit /etc/passwd to change '/bin/sh' back to '/bin/false'

Regards,
Lee


>
>         // RB modified resolv.conf with custom
> /etc/resolvconf/update.d/bind9 to create this file.
>     //include "/run/named/named.resolvers";
>     /* Error was
> May 11 12:46:27 barley named[15935]: loading configuration from
> '/etc/bind/named.conf'
> May 11 12:46:27 barley named[15935]: /etc/bind/named.conf.options:18:
> open: /run/named/named.resolvers: permission denied
> May 11 12:46:27 barley named[15935]: loading configuration: permission
> denied
> May 11 12:46:27 barley named[15935]: exiting (due to fatal error)
>
> The script clearly starts as the bind user, and when I su to bind I
> can cat the file.
> */
>
> Second,  I had a bunch of logging directives like
> logging {
> /*  permission problems opening the log files.  Not sure why.
>   channel update_debug{
>     file "/var/log/bind/dnsupdate.log";
>     severity  debug 3;
>     print-category yes;
>     print-severity yes;
>     print-time yes;
>     };
> */
> /var/log/bind is owned by bind.
>
> For now I just commented the problems out, but I'd like it to work.
> For one thing, my network configuration is not static.
>
> Thanks.
> Ross
>
> *Specifically bind9 (1:9.8.4.dfsg.P1-6+nmu2+deb7u20) wheezy-security
>
>

[toc] | [prev] | [next] | [standalone]

#208676

On Wed, May 15, 2019 at 12:11:58PM -0400, Lee wrote:
> The way I fixed my permission problems after telling bind to log to a
> file instead of syslog was
>   su -
> to become root
>   su bind
> which didn't work because
>   # grep bind /etc/passwd
>   bind:x:116:119::/var/cache/bind:/bin/false
> so edit /etc/passwd and change '/bin/false' to '/bin/sh'
>   su bind
> then worked, so
>   /usr/sbin/named -g
> to see all the errors.  Adjust permissions, start bind as a daemon and
> edit /etc/passwd to change '/bin/sh' back to '/bin/false'

If sudo is installed, you can simply do

sudo -u bind -s

to start a shell as that user despite what /etc/passwd says.  Of course,
you need permission to use sudo.

[toc] | [prev] | [next] | [standalone]

#208679

[Multipart message — attachments visible in raw view] — view raw

I also have a similar problem accessing /run/named.  bind can't create the 
directory or any files in it.  The error messages:

couldn't mkdir '//run/named': Permission denied

could not create //run/named/session.key

Apparmor problems can be fixed by running aa-logprof and selecting the best 
"fix" for your system.  I have done that if needed over the months since 
apparmor was installed.  The other problem is that /run is a type tmpfs so it is 
created after each boot so any manual fixes are lost after a reboot.  I also 
have the same problem for the apt-cacher-ng program.  Since this machine is my 
router for my home network it is rarely rebooted so I have a temporary fix by 
running the following script manually:

cd /run

mkdir named
chown bind.bind named
systemctl restart bind9

mkdir apt-cacher-ng

chown apt-cacher-ng.apt-cacher-ng apt-cacher-ng
systemctl restart apt-cacher-ng


My /etc/bind config directory has no reference to /run.  I do see a 
/run/resolvconf directory which has resolv.conf in it pointing to localhost and 
search domain.  This seems correct since bind is listening on localhost and you 
want to actually use bind to get and cache dns requests.

My bind is version 9.11.5.P4+dfsg-5.

-- 


*...Bob*

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web