abstractions/winbind has rather strange and very outdated profile.
I'm assuming this is pam-winbind and nss-winbind, not winbind daemon -
because for the daemon, much more is needed.

I dont know where all these files listed in there are there.  Neiter
pam nor winbind modules access these files.  The only file they do
access is /run/samba/winbind/pipe - very long time ago it's been in
/tmp/.winbind/pipe, but it has been moved elsewhere (to /var/run,
later to /run) many years ago.  And this is the path which is blocked
by current profile.

Without any prior knowlege of apparmor, I'd say this whole file should
have just one line:

  @{run}/samba/winbind/pipe rw,

Note also that PAM-winbind is different from NSS-winbind - the pam stuff
is for authentication, which is usually done by a priviledged process.
So I *guess* it meant to be nss-winbind in comment, not pam-winbind.

I wonder how it went unnoticed for so many years.

This come to my attention as #1110985 - this one apparently also needs
an ability to create unix sockets (socket(AF_UNIX)) which is blocked
now, but I don't know how to enable this one.  Any help with this bug
is appreciated.

Thanks,

/mjt

Hi,

Michael Tokarev (2025-08-16):
from the authentication and nameservice abstractions.

The Git [history] of this file upstream suggests that the last change
applied to it, apart of mostly-mechanical tree-wide updates, dates
back from 2014. So I'm not surprised if, as you're saying, it is
greatly outdated.

[history] https://gitlab.com/apparmor/apparmor/-/commits/master/profiles/apparmor.d/abstractions/winbind?ref_type=heads

Thanks a lot for this insight. I don't have the means to quickly test
this change and confirm it works, so I won't submit it upstream myself
nor tag this bug report "patch". Are you in a position to do that?

Good question. I guess either the impact on affected users is smaller
than we would expect, or there are fewer affected users than we would
expect, or the affected users silently disable AppArmor and go on with
their day without reporting bugs.

Given the kind of environments where I expect this sort of things to
be deployed, my guess is that the sysadmins who set this up on client
Linux machines deal with it *somehow*, and actual end-users of said
machines never experience the problem.

I'll try to take a look but most likely this will exceed my capacity
for AppArmor work in Debian, so if someone else reading here can help,
this would be much appreciated!

Cheers,