Bug#927747: bind9_dlz backend is entirely broken in Debian
This is https://bugzilla.samba.org/show_bug.cgi?id=14030 and also #1036587 . /mjt
Bug#927747: bind9_dlz backend is entirely broken in Debian
Control: tag -1 + moreinfo So, after reading it all briefly, what is missing in samba still? Can someone with the related knowlege summarize this please? Thanks, /mjt
Bug#927747: bind9_dlz backend is entirely broken in Debian
Control: severity -1 normal On Wed, 8 May 2019 22:35:53 +0200 "Steinar H. Gunderson" wrote: On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote: > Downgrading the severity as the AppArmor side is already fixed it seems in sid. serious and grave are of equal severity; serious is for Policy violations (e.g. package doesn't install), grave is for functionality issues (e.g. program segfaults on start). For some reason it is common to misuse severity. A "package is unusable in almost all configurations" or at least "unusable in default configuration" isn't always equal to "package is unusable *for me*". In this case, if dlz_backend is broken, it does not mean samba is entirely broken. A particular configuration of it - sure. For one, we run a samba AD without dlz_backend and without bind to begin with, and it works just fine.. Thanks, /mjt
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
I would like to add my observations on this bug after upgrading from stretch to 10.1. The apparmor fixes seem OK so far. My samba system was originally created by moving a samba-3 system from CentOS 6 to Debian 9 and then using the samba tools to migrate to an ad-dc system. I mention this, because that migration path, while surprisingly smooth, was not without a need for some manual intervention. So some of what I obseved might be specific to my situation, since it was not installed on Debian from scratch. At the end of the Buster upgrade, everything seemed to be running OK, however once I needed to make some changes to and check the bind9 config the problems became apparent. 1. the bind config was still pointing at /var/lib/samba/private/named.conf and that file was still loading the 9.10 library, rather than 9.11. 2. After fixing that, I ran the suggested test of "samba_dnsupdate --verbose --all-names" and every line reported "failed". 3. I then tried the suggestion from the samba wiki of "samba_upgradedns --dns-backend=BIND9_DLZ" That failed due to the non-existence of the /var/lib/samba/bind-dns directory, which led me to this bug report. I manually created that directory, gave it what I guessed might be suitable group ownership and permissions, and reran the samba_upgradedns script. The result of that was that there were no errors, and the program reported that I needed to manually adjust the two entries in the bind9 config files to point to the new directory. So it seems to me that the problem could be safely fixed by changing the samba_upgradedns script to check for and create the bind-dns folder if necessary. (I suppose that is an upstream issue and the full ramifications would need to be considered) Running this script in postinst would be appropriate, but you would somehow need to determine that the user was already using the bind9_dlz backend. The result of the upgrade script running is that: 1. the new config file is created, that loads the correct version dlz library (but "including" that file needs to be manually edited in main bind9 config (options or local - wiki says .local, but mine was in .options)) 2. the gssapi-key file is created as a hard link between private and bind-dns locations, so old config still works, but user is advised to manually update the bind9 .options file. Cameorn.
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote: > Downgrading the severity as the AppArmor side is already fixed it seems in > sid. serious and grave are of equal severity; serious is for Policy violations (e.g. package doesn't install), grave is for functionality issues (e.g. program segfaults on start). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
severity 927747 serious thanks Le mar. 23 avr. 2019 à 23:12, Steinar H. Gunderson a écrit : > > On Tue, Apr 23, 2019 at 10:24:54PM +0200, Mathieu Parent wrote: > > There are several issues here. Trying a summary. > > 1. We need to patch bind9 apparmor profile (this is the cloned bug) > > Yes. > > > 2. The /var/lib/samba/bind-dns directory is created on domain > > provision. Nothing to do here? > > It's not created on upgrade from stretch, though? You don't re-provision your > domain when upgrading Samba, yet upgrading should be allowed. > > > 2. bind9 conf "include" should be updated. As the conffile is not > > owned by samba all we can do is printing a message in samba preinst > > (if include "/usr/local/samba/private/named.conf" is found in > > /etc/named/named.conf or /etc/bind/named.conf.local) > > Yes. > > > 3.Patching "named.conf" template to load the correct bind9 module (i.e 9.11) > > I _think_ samba_dnsupgradedns writes a new config fragment. > > > 4. Run "samba_upgradedns --dns-backend=BIND9_DLZ", but when? > > I would assume in postinst (assuming we detect its use). > I've started to work on this but was unable to automate things. Will try again Downgrading the severity as the AppArmor side is already fixed it seems in sid. Regards -- Mathieu Parent
Bug#927827: Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
Control: found -1 1:9.11.5.P4+dfsg-1 Control: tags -1 + pending On Tue, Apr 23, 2019 at 10:24:54PM +0200, Mathieu Parent wrote: > +/var/lib/samba/bind-dns/** rwk, > > But we may do better with something like this (to be tested and improved): > >/var/lib/samba/private/dns.keytab r, >/var/lib/samba/private/named.conf r, > - /var/lib/samba/private/dns/** rwk, > + /var/lib/samba/bind-dns/*.conf r, > + /var/lib/samba/bind-dns/dns/** rwk, > - /etc/smb.conf r, > + /etc/samba/smb.conf r, The filename has already been fixed in -2 and I've staged the bind-dns/dns/** part in git. A CVE for bind9 is expected for later today, I'll include it in the next upload. I've marked the version in testing to be affected (which it is), so -2 and -3 can at least migrate. Bernhard
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
Hai, > > 3.Patching "named.conf" template to load the correct bind9 module (i.e 9.11) > I _think_ samba_dnsupgradedns writes a new config fragment. No you need adjustments in bind as shown below. after the 4 points, im missing the following. Addding point 5. The end result should look like this: ls -al /var/lib/samba/bind-dns/ total 28 drwxrwx--- 3 root bind 4096 Apr 24 08:17 . drwxr-xr-x 10 root root 4096 Apr 8 15:03 .. drwxrwx--- 3 root bind 4096 Feb 27 16:38 dns -rw-r- 2 root bind 877 Apr 28 2015 dns.keytab -rw-r--r-- 1 root root 781 Feb 27 16:38 named.conf -r--r--r-- 1 root root 312 Feb 27 16:41 named.conf.update -rw-r--r-- 1 root root 2092 Feb 27 16:38 named.txt Take note that dns.keytab isnt moved by default but should be moved. This is one i did manualy. After that change you need to adjust : /etc/bind/named.conf.options. // https://wiki.samba.org/index.php/Dns-backend_bind // DNS dynamic updates via Kerberos (optional, but recommended) // old path //tkey-gssapi-keytab "/var/lib/samba/private/dns.keytab"; tkey-gssapi-keytab "/var/lib/samba/bind-dns/dns.keytab"; and in : /etc/bind/named.conf.local. change // adding the dlopen ( Bind DLZ ) module for samba, include "/var/lib/samba/bind-dns/named.conf"; Now bind9 restart then samba restart. to make sure the restart order is correct and it always works. systemctl edit samba-ad-dc.service # /etc/systemd/system/samba-ad-dc.service.d/override.conf [Unit] After=network.target network-online.target bind9.service Maybe its an option to add it as default that samba always starts after bind9 started. Greetz, Louis
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
On Tue, Apr 23, 2019 at 10:24:54PM +0200, Mathieu Parent wrote: > There are several issues here. Trying a summary. > 1. We need to patch bind9 apparmor profile (this is the cloned bug) Yes. > 2. The /var/lib/samba/bind-dns directory is created on domain > provision. Nothing to do here? It's not created on upgrade from stretch, though? You don't re-provision your domain when upgrading Samba, yet upgrading should be allowed. > 2. bind9 conf "include" should be updated. As the conffile is not > owned by samba all we can do is printing a message in samba preinst > (if include "/usr/local/samba/private/named.conf" is found in > /etc/named/named.conf or /etc/bind/named.conf.local) Yes. > 3.Patching "named.conf" template to load the correct bind9 module (i.e 9.11) I _think_ samba_dnsupgradedns writes a new config fragment. > 4. Run "samba_upgradedns --dns-backend=BIND9_DLZ", but when? I would assume in postinst (assuming we detect its use). /* Steinar */ -- Homepage: https://www.sesse.net/
Bug#927747: [Pkg-samba-maint] Bug#927747: bind9_dlz backend is entirely broken in Debian
clone 927747 -1 reassign -1 bind9 severity -1 serious retitle -1 bind9: Please add "/var/lib/samba/bind-dns/** rwk," to apparmor profile thanks Le lun. 22 avr. 2019 à 17:30, Steinar H. Gunderson a écrit : > > Package: samba > Version: 2:4.9.5+dfsg-3 > Severity: grave > > Hi, Hi, Thanks for your detailed report. > I upgraded a DC from stretch to buster, and DNS for AD (via bind9_dlz) > started failing in strange ways. (In particular, when I changed the IP address > of the DC, samba-tool dns query would return the correct addresses, but actual > DNS lookups would return the old ones.) It turns out that upstream, bind9_dlz > data has moved from /var/lib/samba/private to /var/lib/samba/bind-dns; > however, > there's no notice about this anywhere, and the path does not exist in Debian. > (Thus, the .conf file in use didn't even mention the BIND 9.11 .so file, much > less load it.) Furthermore, if you try to remedy this problem yourself by > mkdir-ing the new directory and running samba_dnsupgrade, BIND will no longer > start due to AppArmor policies being out of date: > > [84419.640664] audit: type=1400 audit(1555945763.230:88): apparmor="DENIED" > operation="open" profile="/usr/sbin/named" > name="/var/lib/samba/bind-dns/named.conf" pid=9043 comm="isc-worker" > requested_mask="r" denied_mask="r" fsuid=111 ouid=0 > [84486.581899] audit: type=1400 audit(1555945830.170:89): apparmor="DENIED" > operation="open" profile="/usr/sbin/named" > name="/var/lib/samba/bind-dns/named.conf" pid=9171 comm="isc-worker" > requested_mask="r" denied_mask="r" fsuid=111 ouid=0 > > Given that AppArmor now seems to be default on in buster, this breaks > the functionality completely, even for new installations (not just for > upgrades from stretch). > > I would suppose that postinst needs to check whether BIND9_DLZ is in use, > and if so, run samba_upgradedns --dns-backend=BIND9_DLZ and then finally > pop up a message saying that the admin will have to change the .conf path > in named.conf.local. And the AppArmor profile will need to be fixed. > > Even after this, I had to run samba_dnsupdate once with --use-samba-tool, > and then it would finally run without “dns_tkey_gssnegotiate: TKEY is > unacceptable” the next time. There are several issues here. Trying a summary. 1. We need to patch bind9 apparmor profile (this is the cloned bug) 2. The /var/lib/samba/bind-dns directory is created on domain provision. Nothing to do here? 2. bind9 conf "include" should be updated. As the conffile is not owned by samba all we can do is printing a message in samba preinst (if include "/usr/local/samba/private/named.conf" is found in /etc/named/named.conf or /etc/bind/named.conf.local) 3.Patching "named.conf" template to load the correct bind9 module (i.e 9.11) 4. Run "samba_upgradedns --dns-backend=BIND9_DLZ", but when? 1. I think adding this rule is ok: +/var/lib/samba/bind-dns/** rwk, But we may do better with something like this (to be tested and improved): /var/lib/samba/private/dns.keytab r, /var/lib/samba/private/named.conf r, - /var/lib/samba/private/dns/** rwk, + /var/lib/samba/bind-dns/*.conf r, + /var/lib/samba/bind-dns/dns/** rwk, - /etc/smb.conf r, + /etc/samba/smb.conf r, Regards -- Mathieu Parent
Bug#927747: bind9_dlz backend is entirely broken in Debian
Package: samba Version: 2:4.9.5+dfsg-3 Severity: grave Hi, I upgraded a DC from stretch to buster, and DNS for AD (via bind9_dlz) started failing in strange ways. (In particular, when I changed the IP address of the DC, samba-tool dns query would return the correct addresses, but actual DNS lookups would return the old ones.) It turns out that upstream, bind9_dlz data has moved from /var/lib/samba/private to /var/lib/samba/bind-dns; however, there's no notice about this anywhere, and the path does not exist in Debian. (Thus, the .conf file in use didn't even mention the BIND 9.11 .so file, much less load it.) Furthermore, if you try to remedy this problem yourself by mkdir-ing the new directory and running samba_dnsupgrade, BIND will no longer start due to AppArmor policies being out of date: [84419.640664] audit: type=1400 audit(1555945763.230:88): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf" pid=9043 comm="isc-worker" requested_mask="r" denied_mask="r" fsuid=111 ouid=0 [84486.581899] audit: type=1400 audit(1555945830.170:89): apparmor="DENIED" operation="open" profile="/usr/sbin/named" name="/var/lib/samba/bind-dns/named.conf" pid=9171 comm="isc-worker" requested_mask="r" denied_mask="r" fsuid=111 ouid=0 Given that AppArmor now seems to be default on in buster, this breaks the functionality completely, even for new installations (not just for upgrades from stretch). I would suppose that postinst needs to check whether BIND9_DLZ is in use, and if so, run samba_upgradedns --dns-backend=BIND9_DLZ and then finally pop up a message saying that the admin will have to change the .conf path in named.conf.local. And the AppArmor profile will need to be fixed. Even after this, I had to run samba_dnsupdate once with --use-samba-tool, and then it would finally run without “dns_tkey_gssnegotiate: TKEY is unacceptable” the next time. -- System Information: Debian Release: buster/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.0.6 (SMP w/40 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), LANGUAGE=en_NO:en_US:en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages samba depends on: ii adduser 3.118 ii dpkg 1.19.6 ii init-system-helpers 1.56+nmu1 ii libbsd0 0.9.1-2 ii libc62.28-8 ii libldb1 2:1.5.1+really1.4.6-3 ii libpam-modules 1.3.1-5 ii libpam-runtime 1.3.1-5 ii libpopt0 1.16-12 ii libpython2.7 2.7.16-2 ii libtalloc2 2.1.14-2 ii libtdb1 1.3.16-2+b1 ii libtevent0 0.9.37-1 ii libwbclient0 2:4.9.5+dfsg-3 ii lsb-base 10.2019031300 ii procps 2:3.3.15-2 ii python 2.7.16-1 pn python-dnspython pn python-samba ii python2.72.7.16-2 pn samba-common pn samba-common-bin ii samba-libs 2:4.9.5+dfsg-3 pn tdb-tools ii update-inetd 4.49 Versions of packages samba recommends: ii attr1:2.4.48-4 ii logrotate 3.14.0-4 pn samba-dsdb-modules pn samba-vfs-modules Versions of packages samba suggests: pn bind9 pn bind9utils pn ctdb pn ldb-tools ii ntp1:4.2.8p12+dfsg-4 pn smbldap-tools pn ufw pn winbind
