directly edit it so it looks like this:
/usr/bin/irssi flags=(complain) {
Cheers,
--
intrigeri
n README.Debian.
> Would be nice.
Great. I'll do this then :)
If you don't mind, once I have a patch I won't build a test package
locally: I suspect src:libreoffice takes a while to build, and my
changes should boil down to setting ENABLE_APPARMOR_PROFILES=y and
adding README.Debian that dh_installdocs should pick up automatically.
Cheers,
--
intrigeri
tablished system
administration practice, and it should not come as a surprise to any
advanced user who passes a custom profile path to LibreOffice on the
command line.
Cheers,
--
intrigeri
l path?)
If the above does not work, yes.
> One could also just patch it :-)
Absolutely.
Cheers,
--
intrigeri
intrigeri:
> Rene Engelhard:
>>> that everyone else can't benefit from AppArmor security benefits
>>> due to that, so I'm leaning towards:
>>>
>>> 1. keep the AppArmor profile enforced by default, so the vast
>>> majori
AppArmor in Debian is that we want to
avoid creating a culture of "AppArmor breaks stuff so I always disable
it entirely".
Cheers,
--
intrigeri
>From 1afd67ec9f4e68e619f4e707bd62142ba8de78cf Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@boum.org>
Date: Thu, 7 Dec 2017 17:
ting the package from testing/sid (e.g.
uploaders to stretch-backports, Ubuntu maintainers) shall make
their own informed decision. In most cases it's probably a good
idea to disable the AppArmor profiles in backports and stable
distro releases until we reach a decision on #2.
Cheers,
--
intrigeri
in enforce mode instead. See #883800 for the beginning of
this conversation.
The remaining blocker seems to be autopkgtests being broken by
AppArmor, due to using custom paths:
René Engelhard wrote:
> intrigeri wrote:
>> You mentioned something elsewhere about the LibreOffice test suite
>>
Rene Engelhard:
> done already, though in complain mode..
Thanks! I'll follow up on the next steps on a new bug report, quoting
the useful bits from this one :)
Cheers,
--
intrigeri
intrigeri:
> Rene Engelhard:
>> done already, though in complain mode..
> Thanks! I'll follow up on the next steps on a new bug report, quoting
> the useful bits from this one :)
FTR that's #886548.
Vincas Dargis:
> intrigeri, are we getting AppArmor 3 in Buster,
Impossible to predict at this point.
> or else maybe we could backport `mesa` abstraction into AppArmor
> 2.13?
Why not. Create a MR or file a bug against src:apparmor?
Cheers,
--
intrigeri
Vincas Dargis:
> Cool, I will work on MR.
:)))
Also, would be good to have a 2.13.x upstream release with the
fixes/improvements we need.
> "Why not" could be "don't want to manage backports too much" :) .
Right, at least not without being aware of a real need.
Cheers,
--
intrigeri
Vincas Dargis:
> intrigeri, could we get opencl abstractions in 2.13, or we are expecting to
> get AppArmor 3 in Buster?
Sure, gimme a bug against src:apparmor :)
> BTW I have proposed update to use `dri-enumerate` abstraction and remove
> backported rule:
> https://gerrit.libr
13 matches
Mail list logo
