[Pkg-samba-maint] Bug#896080: [pkg-apparmor] Improve samba/AppArmor integration

intrigeri intrigeri at debian.org
Sun Feb 24 17:40:31 GMT 2019


Christian Boltz:
> Am Donnerstag, 21. Februar 2019, 21:26:58 CET schrieb Mathieu Parent:
>> As a last-minute fix for buster, I want to fix "#896080 samba: Improve
>> AppArmor integration" [SambaAppArmor].

Great idea!

>> I've prepared the fixes [Diff], inspired by what is done in Suse. But
>> they also patch apparmor-profiles [AppArmor-Patch]. This solution does
>> not conforms to policy as a file owned by a package could not be
>> changed by another one (/etc/apparmor.d/local/usr.sbin.smbd-shares
>> owned by apparmor-profiles, changed by samba).

I'll assume you mean modifying /etc/apparmor.d/usr.sbin.smbd,
not /etc/apparmor.d/local/usr.sbin.smbd-shares.

> To simplify things, I'd propose to apply a slightly modified version of
> https://build.opensuse.org/package/view_file/openSUSE:Factory/apparmor/apparmor-samba-include-permissions-for-shares.diff?expand=1
> to the usr.sbin.smbd profile in the apparmor-profiles package:

> Instead of   #include   you {c,sh]ould use   #include if exists
> so that it doesn't matter if   local/usr.sbin.smbd-shares   exists or 
> which package creates it.

Absolutely. I'll do that in the src:apparmor I was going to upload

Just one thing: I'd rather include a file that's in
/etc/apparmor.d/samba/ instead of /etc/apparmor.d/local/. The latter
is primarily meant and documented as something for administrators, and
so far all Debian packages that generate policy at runtime store it
elsewhere, e.g. libvirt puts it under /etc/apparmor.d/libvirt/.
I'd rather not confuse users by mixing up different purposes for
/etc/apparmor.d/local/. And then we are in the samba namespace so we
don't need to use the "usr.sbin." prefix. So I'll add this:

   #include if exists /etc/apparmor.d/samba/smbd-shares

Sounds reasonable? If this does not work for you, I'll try to do
another upload in time for the freeze (and worst case you can NMU).

> That might even be an upstream-able solution because it doesn't break 
> distributions without the autogenerated samba profile sniplet (or without
> the package owning that file installed).

Sure, once we've reached an agreement about the included filename :)

> The local/usr.sbin.smbd file can then be owned by whatever package
> (probably samba, because that also owns the script changing the file).

In a Debian context, a file that's automatically generated at runtime
should probably not be owned *in the dpkg sense* by any package.
But for sure, one package must be responsible for that file, and
remove it when the package is purged, and we can thus call it
the owner.


More information about the Pkg-samba-maint mailing list