[pkg-apparmor] Bug#968787: No printer can be installed in cups

intrigeri intrigeri at debian.org
Sun Aug 23 08:50:58 BST 2020


Control: tag -1 + moreinfo

Hi,

Karsten (2020-08-23):
> Yes. But the interesting thing is the output when trying to use cups.
>
> Aug 23 00:59:15 pc kernel: audit: type=1400 audit(1598137155.941:58): apparmor="DENIED" operation="mknod"
> profile="/usr/sbin/cupsd" name="/srv/ssd3/var/spool/cups/00000000" pid=612 comm="cupsd" requested_mask="c"
> denied_mask="c" fsuid=0 ouid=0

It seems you have symlinks from /var/{log,spool} to
/srv/ssd3/{log,spool}, or similar. Could you please confirm?

AppArmor resolves symlinks before applying policy. This is necessary
to avoid anyone bypassing the policy merely by creating a symlink to
a confined program. There's of course no way the default policy
shipped in Debian knows about all the symlinks users may choose to set
up, so some local adjustment will be needed to cope with this
non-standard setup. I consider this as a general usability problem of
AppArmor vs. non-standard setup, rather than a bug in this specific
AppArmor profile.

I think your options are:

A) Use bind-mounts instead of symlinks; I believe this is the cheapest
   option, both in terms of initial setup and in terms of maintenance.
   This avoids AppArmor having to do anything special, because the
   canonical path of /var/{log,spool}/cups will be the one that's
   already supported in the default AppArmor policy.

B) Use the AppArmor "alias" functionality in
   /etc/apparmor.d/tunables/alias, so that AppArmor knows the mapping
   between standard canonical paths and your custom local ones.

   For example, something like this:

     alias /var/spool/cups/ -> /srv/ssd3/var/spool/cups/,

Please try one of these :)



More information about the pkg-apparmor-team mailing list