As predicted, the winbindd part works but unbound still fails to start with the same errors.
The worst problems are those where you are asking yourself how they ever worked. I am definitely not the AppArmor resource you're looking for; I completely defer to you on how to proceed. On Fri, Aug 15, 2025 at 10:23 AM Michael Tokarev <[email protected]> wrote: > > I never used apparmor before. > > Now, looking at all this, I don't see how it is supposed to work. > > First, there's a bug in apparmor package, namely, its > /etc/apparmor.d/abstractions/winbind (for nss-winbind, which is in > use here) lists /tmp/.winbindd/pipe, which moved to /run/winbind/pipe > more than a decade ago. I wonder how it hasn't been noticed so far. > This needs to be fixed. > > Second, none of the files included from > /etc/apparmor.d/abstractions/nameservice > allow unix sockets, while allowing inet/inet6 stream/dgram sockets. > But unix sockets are used - by nss-winbind, nss-systemd etc. I've > no idea how it is supposed to work in the first place, - with this, > common nss modules wont work (as we see here). I bet there are some > other nss modules used in this configuration - something like > nss-systemd, which is where other unix sockets comes from. > > Third, I don't even know how to enable unix sockets creation in > an apparmor profile. It should be enabled in nameservice-strict > abstraction already (but see 2nd above). > > Overall, it all looks like bugs in apparmor package, not in unbound, > since unbound can't be responsible for nss configuration. > > So, I need help with this stuff. Maybe I should reassign this bug > to where it actually belongs. > > At least, try adding these to /etc/apparmor.d/local/usr.sbin.unbound: > > unix, > # pam_winbindd > /run/winbindd/pipe rw, > > I dunno if this will work or not - the "unix" part. > winbind part should work. > > Thanks, > > /mjt
