Debian 11: evince and apparmor flood kernel log

[Roger Price]

In Debian 11, evince has an appamor profile which floods the kernel log with
hundreds of messages of the style:

[24216.325764] audit: type=1400 audit(1631892398.580:255): apparmor="DENIED"
operation="open" profile="/usr/bin/evince"
name="/mnt/home/rprice/.local/share/gvfs-metadata/home" pid=2229
comm="pool-evince" requested_mask="r" denied_mask="r" fsuid=2108 ouid=2108

and floods the console with messages such as

(evince:2869): GVFS-WARNING **: 22:18:18.510: can't init metadata tree /mnt/home/rprice/.local/share/gvfs-metadata/home: open: Permission denied
** (evince:2869): WARNING **: 22:18:18.510: Error setting file metadata: can’t open metadata tree

Command ls -l /mnt/home/rprice/.local/share/gvfs-metadata/home reports

-rw------- 1 rprice cs-users 800 Aug 18 10:48 /mnt/home/rprice/.local/share/gvfs-metadata/home

Quoting file /etc/apparmor.d/usr.bin.evince:

# evince is not written with application confinement in mind and is designed to
# operate within a trusted desktop session where anything running within the
# user's session is trusted.

I solved the problem by switching to mupdf, but mupdf is not as complete as
evince.

Is there some way of calming evince+appamor?

Roger

[Reco]

Hi.

On Fri, Sep 17, 2021 at 10:54:32PM +0200, Roger Price wrote:
> I solved the problem by switching to mupdf, but mupdf is not as complete as evince.

It's customary to add "YMMV" to such statements. Just saying.

> Is there some way of calming evince+appamor?

Pick whatever suits you:

Quick-and-dirty, but wrong way (apparmor is good, do not disable it
unless you know what you're doing):

/usr/sbin/aa-disable /usr/bin/evince


Easy, but wrong way (aa-logprof is only good for user-defined profiles,
and you *will* get complicated upgrades):

aa-logprof
# accept whatever the thing will show you


A correct way, but it may require more than one iteration:

echo '/mnt/home/rprice/.local/share/gvfs-metadata/home r,' >> /etc/apparmor.d/local/usr.bin/evince

aa-complain /usr/bin/evince
aa-enforce /usr/bin/evince

Reco

[Klaus Singvogel]

Roger Price wrote:
> In Debian 11, evince has an appamor profile which floods the kernel log with
> hundreds of messages of the style:

Not only at Debian 11, even Debian 10 has it.

[...]

> (evince:2869): GVFS-WARNING **: 22:18:18.510: can't init metadata tree /mnt/home/rprice/.local/share/gvfs-metadata/home: open: Permission denied

[...]

> Is there some way of calming evince+appamor?

The location of your home is uncommon (as on my side).

Fix: edit /etc/apparmor.d/tunables/home.d/site.local

Best regards,
Klaus.
--
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D 1994-06-27

[Roger Price]

On Sat, 18 Sep 2021, Klaus Singvogel wrote:

> Roger Price wrote:
>> In Debian 11, evince has an appamor profile which floods the kernel log with
>> hundreds of messages of the style:
>
> Not only at Debian 11, even Debian 10 has it.
>
> [...]
>> (evince:2869): GVFS-WARNING **: 22:18:18.510: can't init metadata tree /mnt/home/rprice/.local/share/gvfs-metadata/home: open: Permission denied
> [...]
>> Is there some way of calming evince+appamor?
>
> The location of your home is uncommon (as on my side).
>
> Fix: edit /etc/apparmor.d/tunables/home.d/site.local

In site.local I found

# The following is a space-separated list of where additional user home
# directories are stored, each must have a trailing '/'. Directories added
# here are appended to @{HOMEDIRS}. See tunables/home for details. Eg:
#@{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/

where curiously, the apparmor installation seems to have detected my non-common
/home and made the necessary addition, but appended to a commented out example.

I added line /mnt/home/ and tried to restart apparmor.service. This failed with
error messages such as

Sep 18 12:08:33 titan apparmor.systemd[5150]: AppArmor parser error for
/etc/apparmor.d/lsb_release in /etc/apparmor.d/tunables/multiarch at line 13:
syntax error
Sep 18 12:08:33 titan apparmor.systemd[5154]: AppArmor parser error for
/etc/apparmor.d/nvidia_modprobe in /etc/apparmor.d/tunables/multiarch at line
13: syntax error

So I tried replacing @{HOMEDIRS}=/home/ with @{HOMEDIRS}=/mnt/home/ in file
/etc/apparmor.d/tunables/home

I restarted apparmor.service and some light testing shows that the problem is
solved.

My error in site.local was probably to have added /mnt/home and not
@{HOMEDIRS}+=/mnt/home

Thanks to all who responded! Roger

[Greg Wooledge]

On Sat, Sep 18, 2021 at 12:54:36PM +0200, Roger Price wrote:
> In site.local I found
>
> # The following is a space-separated list of where additional user home
> # directories are stored, each must have a trailing '/'. Directories added
> # here are appended to @{HOMEDIRS}. See tunables/home for details. Eg:
> #@{HOMEDIRS}+=/srv/nfs/home/ /mnt/home/
>
> where curiously, the apparmor installation seems to have detected my
> non-common /home and made the necessary addition, but appended to a
> commented out example.

It wasn't "detected". That's the generic site.local file that everyone
has. The commented-out line is provided as an example.

What you're supposed to do is either:

(a) Uncomment that last line, and edit it.

(b) Copy that last line, uncomment the copy, and edit the copy.

I prefer (b) myself.

[David Wright]

Yes, it's pretty obvious what's going on if you actually do
"See tunables/home for details", because that has the =
definition that the += is appending to.

<nitpick>

But — the last line of that comment above is actually inconsistent
with how comments are written in /etc/apparmor* files. It should
have a space after the #. #include lines are the only ones that don't.

The other files that look wrong are /etc/apparmor.d/tunables/*.d/*
and /etc/apparmor.d/tunables{kernelvars,sys}.

</nitpick>

Cheers,
David.