[pkg-apparmor] Bug#1111245: wrong profile for winbind

[intrigeri]

Control: tag -1 + upstream

Hi,

Michael Tokarev (2025-08-16):
> 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.

Yes, this traks: on my system I see this abstraction is only included
from the authentication and nameservice abstractions.

> 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.

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

> Without any prior knowlege of apparmor, I'd say this whole file should
> have just one line:
>
>   @{run}/samba/winbind/pipe rw,

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?

> I wonder how it went unnoticed for so many years.

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.

> 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.

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,
-- 
intrigeri