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

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

2018-02-04 Thread Ben Caradoc-Davies 
Rebooting restores man page rendering, even with 2.8.0-1, but 
reinstalling causes the bug to reappear.


It looks like root can view man pages but an unprivileged user cannot.

Kind regards,

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

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

2018-02-04 Thread Axel Beckert 
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.

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.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

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

2018-02-04 Thread Debian Bug Tracking System 
Processing control commands:

> merge 889608 -1
Bug #889608 [man-db] man-db: man(1) dumps core (AppArmor involved)
Bug #889617 [man-db] man-db: all man pages fail to display with "command exited 
with status 4"
Merged 889608 889617

-- 
889608: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889608
889617: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

2018-02-04 Thread Ben Caradoc-Davies 
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.
3 profiles are loaded.
3 profiles are in enforce mode.
   /usr/bin/man
   /usr/bin/man//filter
   /usr/bin/man//groff
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

Kind regards,

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

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

2018-02-04 Thread Ben Caradoc-Davies 

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

Feb 05 13:09:30 ripley audit[30186]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/preconv" pid=30186 comm="man" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.641:103): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/preconv" 
pid=30186 comm="man" requested_mask="x" denied_mask="x" fsuid=1000 
ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley audit[30187]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/tbl" pid=30187 comm="man" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.641:104): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/tbl" pid=30187 
comm="man" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0 
target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley audit[30195]: AVC apparmor="DENIED" 
operation="exec" info="no new privs" error=-1 profile="/usr/bin/man" 
name="/usr/bin/troff" pid=30195 comm="groff" requested_mask="x" 
denied_mask="x" fsuid=1000 ouid=0 target="/usr/bin/man//groff"
Feb 05 13:09:30 ripley kernel: audit: type=1400 
audit(1517789370.645:105): apparmor="DENIED" operation="exec" info="no 
new privs" error=-1 profile="/usr/bin/man" name="/usr/bin/troff" 
pid=30195 comm="groff" requested_mask="x" denied_mask="x" fsuid=1000 
ouid=0 target="/usr/bin/man//groff"


With 2.7.6.1-4+b1, there are no messages.

Kind regards,

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

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

2018-02-04 Thread Ben Caradoc-Davies 
Package: man-db
Version: 2.8.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

(Where "all" means all those I tested including "man", "ls", "tar", "git
commit".)

Workaround is to downgrade man-db to 2.7.6.1-4+b1.

Kind regards,
Ben.



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages man-db depends on:
ii  bsdmainutils   11.1.2
ii  debconf [debconf-2.0]  1.5.65
ii  dpkg   1.19.0.5
ii  groff-base 1.22.3-9
ii  libc6  2.26-6
ii  libgdbm5   1.14.1-2
ii  libpipeline1   1.5.0-1
ii  libseccomp22.3.1-2.1
ii  zlib1g 1:1.2.8.dfsg-5

man-db recommends no packages.

Versions of packages man-db suggests:
ii  apparmor2.12-2
ii  firefox [www-browser]   58.0.1-1
ii  google-chrome-stable [www-browser]  64.0.3282.140-1
pn  groff   
ii  less487-0.1

-- debconf information:
  man-db/auto-update: true
  man-db/install-setuid: false