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

[intrigeri]

Hi,

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

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.

Cheers,
-- 
intrigeri