Upcoming change: rsyslog's apparmor enforced by default

[Andreas Hasenack]

Hi Steve,

On Sun, Feb 12, 2023 at 2:48 AM Steve Langasek
<steve.langasek at ubuntu.com> wrote:
>
> Hi Andreas,
>
> On Sat, Feb 11, 2023 at 02:45:17PM -0300, Andreas Hasenack wrote:
> > Hi,
>
> > In the next few days, if all goes according to plan, I'll upload
> > rsyslogd to lunar with a change[1] to the way its apparmor profile is
> > applied.
>
> > The confinement status won't be changed during upgrades, but fresh
> > installs will have the apparmor profile enforced by default. Up until
> > now, it's been disabled.
>
> Can you elaborate on this decision not to change the behavior on upgrade?
> It's expected on upgrade between releases that behavior will change; and to

Hmm, you are right, I was thinking in the context of lunar to lunar
upgrades, and not release upgrades, which is what we are aiming for.

> not enforce for upgrading users means a difference in configs between new
> installs and upgrades that complicates the support matrix over the long
> term.
>
> I am strongly in favor of making the behavior on upgrade conform to the
> behavior on new installs - even if that means there might be some unpleasant
> surprises where the package fails to configure because of apparmor being
> enabled.  That seems unlikely to me in any case; even if the user has
> diverged from the stock rsyslog config, it seems more likely to me that the
> daemon would still start up but might in some cases fail to log.  Again,

Correct, I'm not failing the startup because apparmor failed to apply
or load, and that is in line with current rsyslog's behavior towards
its plugins. If a plugin fails to write a log (like mysql is not
available, or apparmor prevented it from doing so), it will just keep
retrying in the background, instead of failing the whole daemon or the
logging to other places.

I'll make the change, thanks for the feedback!