gettimeofday({1439915504, 207978}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2102, ...}) = 0 write(2, "18-Aug-2015 18:31:44.207 added l"..., 6118-Aug-2015 18:31:44.207 added libseccomp rule: gettimeofday ) = 61 gettimeofday({1439915504, 208196}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2102, ...}) = 0 write(2, "18-Aug-2015 18:31:44.208 added l"..., 5518-Aug-2015 18:31:44.208 added libseccomp rule: unlink ) = 55 gettimeofday({1439915504, 208759}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2102, ...}) = 0 write(2, "18-Aug-2015 18:31:44.208 added l"..., 5618-Aug-2015 18:31:44.208 added libseccomp rule: fcntl64 ) = 56 prctl(PR_SET_NO_NEW_PRIVS, 0x1, 0, 0, 0) = 0 prctl(PR_SET_SECCOMP, 0x2, 0x8104580, 0, 0) = 0 gettimeofday({1439915504, 209697}, NULL) = 0 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2102, ...}) = 0 write(2, "18-Aug-2015 18:31:44.209 libsecc"..., 5418-Aug-2015 18:31:44.209 libseccomp sandboxing active ) = 54 rt_sigaction(SIGHUP, {0xb74dbe16, ~[RTMIN RT_1], SA_RESTORER, 0xb6ff3bf8}, NULL, 8) = 0 gettimeofday({1439915504, 210489}, NULL) = 0 brk(0x8180000) = 0x8180000 socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 6 bind(6, {sa_family=AF_NETLINK, pid=0, groups=00000110}, 12) = 0 fcntl64(6, F_DUPFD, 20) = 20 close(6) = 0 fcntl64(20, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(20, F_SETFL, O_RDWR|O_NONBLOCK) = 0 +++ killed by SIGSYS +++ Bad system call Reproducible: Always Steps to Reproduce: 1. rebuilt bind.. now comes with default flag seccomp 2. restart fails.. 3. Actual Results: See description which is made by adding -g to the command line and running it on screen from strace. Expected Results: starting bind? rebuilding without seccomp flag allows named to start.
Same issue on a fresh amd64 machine with seccomp.
Can confirm this behaviour as well. Workaround with USE="-seccomp" confirmed as well. Also apparently installing syslog-ng helps just as well (instead of compiling named with USE="-seccomp")
Felix, could you please elaborate on what you mean by "installing syslog-ng helps" ? I am using syslog-ng, but bind with seccomp fails to start regardless of that.
(In reply to Felix Krohn from comment #2) > Also apparently installing syslog-ng helps just as well (instead of > compiling named with USE="-seccomp") +1 to comment #3 Logs of success start: Aug 18 08:44:21 mydesktop named[2676]: starting BIND 9.10.2-P2 -u named Aug 18 08:44:21 mydesktop named[2676]: built with '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--disable-threads' '--without-dlopen' '--without-dlz-filesystem' '--without-dlz-stub' '--without-dlz-postgres' '--without-dlz-mysql' '--without-dlz-bdb' '--without-dlz-ldap' '--without-dlz-odbc' '--with-openssl=/usr' '--with-ecdsa' '--without-idn' '--disable-ipv6' '--without-libxml2' '--without-gssapi' '--disable-rpz-nsip' '--disable-rpz-nsdname' '--enable-linux-caps' '--without-gost' '--disable-filter-aaaa' '--disable-fixed-rrset' '--without-python' '--disable-seccomp' '--without-libjson' '--without-readline' '--with-randomdev=/dev/random' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=native -O2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' Aug 18 08:44:21 mydesktop named[2676]: ---------------------------------------------------- Aug 18 08:44:21 mydesktop named[2676]: BIND 9 is maintained by Internet Systems Consortium, Aug 18 08:44:21 mydesktop named[2676]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Aug 18 08:44:21 mydesktop named[2676]: corporation. Support and training for BIND 9 are Aug 18 08:44:21 mydesktop named[2676]: available at https://www.isc.org/support Aug 18 08:44:21 mydesktop named[2676]: ---------------------------------------------------- Aug 18 08:44:21 mydesktop named[2676]: using 1 UDP listener per interface Aug 18 08:44:21 mydesktop named[2676]: using up to 4096 sockets Aug 18 08:44:21 mydesktop named[2676]: loading configuration from '/etc/bind/named.conf' Aug 18 08:44:21 mydesktop named[2676]: reading built-in trusted keys from file '/etc/bind/bind.keys' Aug 18 08:44:21 mydesktop named[2676]: using default UDP/IPv4 port range: [1024, 65535] Aug 18 08:44:21 mydesktop named[2676]: using default UDP/IPv6 port range: [1024, 65535] Aug 18 08:44:21 mydesktop named[2676]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 18 08:44:21 mydesktop named[2676]: generating session key for dynamic DNS Aug 18 08:44:21 mydesktop named[2676]: sizing zone task pool based on 3 zones Aug 18 08:44:21 mydesktop named[2676]: set up managed keys zone for view _default, file 'managed-keys.bind' Aug 18 08:44:21 mydesktop named[2676]: command channel listening on 127.0.0.1#953 Aug 18 08:44:21 mydesktop named[2676]: managed-keys-zone: loaded serial 0 Aug 18 08:44:21 mydesktop named[2676]: zone localhost/IN: loaded serial 2008122601 Aug 18 08:44:21 mydesktop named[2676]: all zones loaded Aug 18 08:44:21 mydesktop named[2676]: running No result report. The result can be retored by turning off record: Aug 18 18:00:11 mydesktop named[2676]: shutting down Aug 18 18:00:11 mydesktop named[2676]: stopping command channel on 127.0.0.1#953 Aug 18 18:00:11 mydesktop named[2676]: no longer listening on 127.0.0.1#53 Aug 18 18:00:11 mydesktop named[2676]: exiting Logs of failure: Aug 19 08:49:00 mydesktop named[2675]: starting BIND 9.10.2-P3 -u named Aug 19 08:49:00 mydesktop named[2675]: built with '--prefix=/usr' '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib64' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--disable-threads' '--without-dlopen' '--without-dlz-filesystem' '--without-dlz-stub' '--without-dlz-postgres' '--without-dlz-mysql' '--without-dlz-bdb' '--without-dlz-ldap' '--without-dlz-odbc' '--with-openssl=/usr' '--with-ecdsa' '--without-idn' '--disable-ipv6' '--without-libxml2' '--without-gssapi' '--disable-rpz-nsip' '--disable-rpz-nsdname' '--enable-linux-caps' '--without-gost' '--disable-filter-aaaa' '--disable-fixed-rrset' '--without-python' '--enable-seccomp' '--without-libjson' '--without-readline' '--with-randomdev=/dev/random' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=native -O2 -pipe' 'LDFLAGS=-Wl,-O1 -Wl,--as-needed' Aug 19 08:49:00 mydesktop named[2675]: ---------------------------------------------------- Aug 19 08:49:00 mydesktop named[2675]: BIND 9 is maintained by Internet Systems Consortium, Aug 19 08:49:00 mydesktop named[2675]: Inc. (ISC), a non-profit 501(c)(3) public-benefit Aug 19 08:49:00 mydesktop named[2675]: corporation. Support and training for BIND 9 are Aug 19 08:49:00 mydesktop named[2675]: available at https://www.isc.org/support Aug 19 08:49:00 mydesktop named[2675]: ---------------------------------------------------- Aug 19 08:49:00 mydesktop named[2675]: using 1 UDP listener per interface Aug 19 08:49:00 mydesktop named[2675]: using up to 4096 sockets Aug 19 08:49:00 mydesktop named[2675]: libseccomp sandboxing active Aug 19 08:49:00 mydesktop named[2675]: loading configuration from '/etc/bind/named.conf' Aug 19 08:49:00 mydesktop named[2675]: reading built-in trusted keys from file '/etc/bind/bind.keys' Aug 19 08:49:00 mydesktop named[2675]: using default UDP/IPv4 port range: [1024, 65535] Aug 19 08:49:00 mydesktop named[2675]: using default UDP/IPv6 port range: [1024, 65535] Aug 19 08:49:00 mydesktop named[2675]: listening on IPv4 interface lo, 127.0.0.1#53 Aug 19 08:49:00 mydesktop named[2675]: generating session key for dynamic DNS Aug 19 08:49:00 mydesktop named[2675]: sizing zone task pool based on 3 zones Aug 19 08:49:00 mydesktop named[2675]: set up managed keys zone for view _default, file 'managed-keys.bind' Aug 19 08:49:00 mydesktop named[2675]: command channel listening on 127.0.0.1#953 Aug 19 08:49:00 mydesktop kernel: audit: type=1326 audit(1439963340.402:2): auid=4294967295 uid=40 gid=40 ses=4294967295 subj=kernel pid=2675 comm="named" exe="/usr/sbin/named" sig=31 arch=c000003e syscall=125 compat=0 ip=0x7f91c164a4b7 code=0x0 Aug 20 08:49:27 mydesktop named[2588]: starting BIND 9.10.2-P3 -u named And no messages about switching off. So, daemon was not started. Again no result message in logs. I see no difference with success. Trying to add -d option changed nothing. This (no messages about failure) may be (or should be) a question (feature request) for upstream.
(In reply to Sergey S. Starikoff from comment #4) Ops. Logs differs. The error end point is: Aug 19 08:49:00 mydesktop kernel: audit: type=1326 audit(1439963340.402:2): auid=4294967295 uid=40 gid=40 ses=4294967295 subj=kernel pid=2675 comm="named" exe="/usr/sbin/named" sig=31 arch=c000003e syscall=125 compat=0 ip=0x7f91c164a4b7 code=0x0 Instead of: Aug 18 08:44:21 mydesktop named[2676]: managed-keys-zone: loaded serial 0 So, P3 patch isn't completely correct.
(In reply to Nico Baggus from comment #0) > Steps to Reproduce: > 1. rebuilt bind.. now comes with default flag seccomp Um, no. There is no default seccomp. Where did you get that from?
(In reply to Christian Ruppert (idl0r) from comment #6) > (In reply to Nico Baggus from comment #0) > > Steps to Reproduce: > > 1. rebuilt bind.. now comes with default flag seccomp > > Um, no. There is no default seccomp. Where did you get that from? Nvm. https://archives.gentoo.org/gentoo-dev/message/38503d86a1c41bccfa607745467b1be7 Looks like we'll start adding global defaults for any kind of flags...
Created attachment 409700 [details] emerge --info "net-dns/bind" Hello, I noticed this behaviour, but I would like to say this daemon only fails to start during a runlevel boot, not during a running system, when using "rc-service named start". I have no idea why, and during the runlevel, the "[ok]" green string is printed. For informations, I attached my emerge --info output. Thanks for support.
A coredump using debug flags would be interesting.
As i only have DNS usable on my production gateway not quickly done. and the latest update with unwanted default.... had some serious side effects on the laptops/phones/tablets behind it. and i still have to fixup the fallout between dhcp & dns. My first post contains an strace from the startup where it fails + -g flag. (debug + errors to stdout). and the flags is definitly enabled by default now.... as i needed to add net-dns/bind -seccomp to get a working version. a change in global defaults would be nice to be known before it is set. last year there were more outages due to sudden changes where no communication was done about these flags. it was possible to do such a globals change with announcement for KDE w.r.t. nepomuk flag. One i endorse as i suspect that nepomuk breaks more then it fixes.
Bluntly, it seems named cannot handle seccomp as it currently stands. There are syscalls it makes that are not being accounted for. For me, it's dying when trying to call uname(2).
(In reply to Thibaud "thican" CANALE from comment #8) > I noticed this behaviour, but I would like to say this daemon only fails to > start during a runlevel boot, not during a running system, when using > "rc-service named start". > > I have no idea why, and during the runlevel, the "[ok]" green string is > printed. For me named is started on default runlevel: # rc-update show | grep named named | default Start fails both at boot-time and at after-boot execution: # service named start (In reply to Christian Ruppert (idl0r) from comment #9) > A coredump using debug flags would be interesting. I've enabled core dumps writing on my box. But named just failes to start. Whithout producing a core dump. Or there is a way to force it?
(In reply to Sergey S. Starikoff from comment #12) > For me named is started on default runlevel: > # rc-update show | grep named > named | default > > Start fails both at boot-time and at after-boot execution: > # service named start Just an FYI, if you killall named you can then preform: service named start
Doing "killall named" followed by "service named start" does not work for me (and I can't think of a reason why it would). The problem, as I understand it, is named is performing an audited syscall, which seccomp is specifically designed to disallow.
it worked for me, allowed me to browse to this bug find a temp fix so I could get on with life. Sorry for the extra noise.
(In reply to Nico Baggus from comment #10) > As i only have DNS usable on my production gateway not quickly done. > and the latest update with unwanted default.... had some serious side effects > on the laptops/phones/tablets behind it. > > and i still have to fixup the fallout between dhcp & dns. > > My first post contains an strace from the startup where it fails + -g flag. > (debug + errors to stdout). > > and the flags is definitly enabled by default now.... > as i needed to add net-dns/bind -seccomp to get a working version. > a change in global defaults would be nice to be known before it is set. > last year there were more outages due to sudden changes where no > communication was done about these flags. > > it was possible to do such a globals change with announcement for KDE w.r.t. > nepomuk flag. One i endorse as i suspect that nepomuk breaks more then it > fixes. First of all https://archives.gentoo.org/gentoo-dev/message/38503d86a1c41bccfa607745467b1be7 So it's not a bind default, it's a global default. It has been "discussed" and I haven't noticed it either. But it's still not the fault of anybody from Gentoo. It's your job to check on ANY update/change whether it fits your need or not and whether it works or not. Blindly upgrading a prod. system and blaming others wont work and often results in unnecessary outages, as you already have noticed. On the other hand, you're right. I don't know why it has been added as a default either for just 8 packages. I did use-mask net-dns/bind[seccomp] for now.
OK, but not really. This type of mentality is only too prevalent in the software industry, for example, and that's how we end up with products where the end user effectively does the testing that should have been done before releasing the product in the first place. If you expect users to individually vet any change devs make into the _profile_, then the implicit trust relationship (devs know what they are doing) simply disappears. I understand switching a USE flag on for an individual package, as this comes with the assumption that whoever is responsible for that package did some minimal testing in the least. But when you switch a flag on for the entire profile, with no regards to what that flag will do to something as critical as bind, ... well. Do you really expect users to follow dev mailing lists? Because it's not a realistic expectation. Now I wasn't hit too hard by this, as I have backup DNS servers and I didn't upgrade everything at the same time, but it was an annoyance nonetheless. What happened is that the USE flag got toggled, but at the same time there was a new version of bind that got stabilized. So I had to spend some time trying to figure out what exactly went wrong. To say that this is not the fault of anybody at Gentoo is just passing the blame. I didn't toggle that flag, that I can tell you. Stejarel
> First of all > https://archives.gentoo.org/gentoo-dev/message/ > 38503d86a1c41bccfa607745467b1be7 > So it's not a bind default, it's a global default. It has been "discussed" > and I haven't noticed it either. But it's still not the fault of anybody > from Gentoo. It's your job to check on ANY update/change whether it fits > your need or not and whether it works or not. Blindly upgrading a prod. > system and blaming others wont work and often results in unnecessary > outages, as you already have noticed. On the other hand, you're right. I > don't know why it has been added as a default either for just 8 packages. > > I did use-mask net-dns/bind[seccomp] for now. So you suggest that i now start following ALL of the DEV lists (and announcements etc.) for about all 1500 Products that i use on Gentoo... and then ALSO fathom all implications that mixing all stuff causes... seems a hard nut to crack. Q: why is the nepomuk change worthy of an announcement and seccomp not.
Because the varying results probably are influenced by use flags here are mine: [I] net-dns/bind Installed versions: 9.10.2_p3^t(19:23:53 08/18/15)(berkdb caps dlz idn ipv6 ldap mysql odbc python ssl urandom xml -doc -filter-aaaa -fixed-rrset -geoip -gost -gssapi -json -nslint -postgres -rpz -seccomp -selinux -static-libs -threads PYTHON_TARGETS="python2_7 python3_4 -python3_3") Homepage: http://www.isc.org/software/bind Description: BIND - Berkeley Internet Name Domain - Name Server The reinstall time is for the compilations without seccomp
(In reply to Christian Ruppert (idl0r) from comment #16) > So it's not a bind default, it's a global default. If seccomp notably improves security, rolling back it's defaul may be just temporary workaround. It may be not bind's default. But bind should work with it. The failure (this bug subject) is an error. And should be reported upstream. Anybody tried to do it? Or know such thread?
(In reply to Sergey S. Starikoff from comment #20) > (In reply to Christian Ruppert (idl0r) from comment #16) > > So it's not a bind default, it's a global default. > > If seccomp notably improves security, rolling back it's defaul may be just > temporary workaround. > It may be not bind's default. > But bind should work with it. The failure (this bug subject) is an error. > And should be reported upstream. > Anybody tried to do it? Or know such thread? This is indeed an upstream bug. I haven't reported anything yet nor did I have the time to look further at it.
Not in tree anymore, can be closed i guess.
