Bug#889608: Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

2018-02-04 Thread intrigeri
Ben Caradoc-Davies:
>> Ben Caradoc-Davies wrote:
>>> And what I would like to know is how the fscking apparmor module got
>>> loaded in the first place, given that I have the apparmor service
>>> masked:
>>> # ls -al /etc/systemd/system/apparmor.service
>>> lrwxrwxrwx 1 root root 9 Dec  8 11:24
>>> /etc/systemd/system/apparmor.service -> /dev/null
>>> Yet:
>>> # aa-status
>>> apparmor module is loaded.
>> You've masked a systemd service. But "module" probably refers to some
>> kernel module here, which is enabled by default since a while in
>> Debian Unstable.

More precisely "module" in this context is to be understood as in
Linux Security Module (LSM). To fully disable the AppArmor LSM, pass
apparmor=0 on the kernel command line (security= might be needed on
top of that, didn't check recently, sorry). Marking/disabling
apparmor.service merely prevents policy loading on boot and might not
be what you want.

Cheers,
-- 
intrigeri



Bug#889608: Bug#889617: man-db: all man pages fail to display with "command exited with status 4"

2018-02-04 Thread Ben Caradoc-Davies

On 05/02/18 13:40, Axel Beckert wrote:

Control: merge 889608 -1
Hi Ben,
thanks for the bug report.
Ben Caradoc-Davies wrote:

under man-db 2.8.0-1 amd64 all man pages fail to display with:
$ man man
man: command exited with status 4: /usr/lib/man-db/zsoelim | /usr/lib/man-
db/manconv -f UTF-8:ISO-8859-1 -t UTF-8//IGNORE | preconv -e UTF-8 | tbl |
nroff -mandoc -rLL=184n -rLT=184n -Tutf8

Ben Caradoc-Davies wrote:

With 2.8.0-1, I see AppArmor messages in the systemd journal for "man man":

This sounds like https://bugs.debian.org/889608 reported only shortly
before your bug report. Hence merging.


Thanks, Axel. I just read the MAN_DISABLE_SECCOMP=1 discussion in 
#889608 and I concur that they are likely the same apparmor problem.



Ben Caradoc-Davies wrote:

And what I would like to know is how the fscking apparmor module got
loaded in the first place, given that I have the apparmor service
masked:
# ls -al /etc/systemd/system/apparmor.service
lrwxrwxrwx 1 root root 9 Dec  8 11:24
/etc/systemd/system/apparmor.service -> /dev/null
Yet:
# aa-status
apparmor module is loaded.

You've masked a systemd service. But "module" probably refers to some
kernel module here, which is enabled by default since a while in
Debian Unstable.


Yes, I think you are right. I am guessing that the man-db package 
install phase dh_apparmor command loads or enables the kernel apparmor 
module and the man apparmor profile. Masking apparmor.service only 
prevents profile loading at boot time, but this is why rebooting with 
apparmor.service masked restore man functionality.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand