Control: reassign -1 man-db 2.8.0-1
On Sun, Jun 24, 2018 at 03:40:55AM +0200, Boris Jakubith wrote:
> I found out this problem after debugging 'dwww' which no longer created any
> output for manual pages. After near 3 hours of debugging i found that the
> command
>
> man -EUTF-8 -P/bin/cat -l "/usr/share/man/man1/7z.1.gz" | dwww-txt2html
> --man --utf8
>
> crashed with the following message:
>
> man: nroff: Bad system call
> man: command exited with status 159: /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 -Tutf8
>
> The same command worked without problems in a shell (with the normal
> environment). Using 'env -i ... man ...' with all environment variables
> supplied and eliminating the environment variables one by one, the command
> crashed with the error message above after i eliminated 'SHELL=/bin/bash'.
>
> This leads me to a work-around for 'dwww'. Insert in 'dwww-convert' near line
> 248 an environment setting for 'SHELL':
>
> $ENV{'SHELL'} = '/bin/sh';
>
> This should solve the problems with 'dwww', but if some other programs use
> 'man' with a limited environment, this problem may occur, too.
The bug is in man-db, not in nroff. It seems familiar, and I thought I
remembered debugging this before, but I can't find a record of it.
What's happening is quite complicated, and it's as follows:
* since version 2.8.0, man-db has used a seccomp filter to try to
reduce the user's exposure to security vulnerabilities caused by
maliciously-crafted manual pages (currently theoretical, but groff is
complex enough that there's no good reason to believe that it will
always be theoretical);
* if SHELL is unset when bash starts (I think this is specific to bash,
so it will depend on what /bin/sh points to on your system), then it
does some extra initialisation steps that involve a call to getpwuid;
* in glibc, getpwuid tries to contact nscd via a Unix socket to see if
it's running;
* the resulting socket syscall is denied by man-db's seccomp filter, on
the basis that at least in the abstract there's no good reason for a
pure text filter to be talking to a socket.
I'm not yet sure what the best solution is. Fiddling about with SHELL
is obviously brittle. I could change man to call groff directly rather
than nroff, which would avoid the problem, but that's also brittle as it
depends on the implementation language. I suspect that I'll just have
to allow sockets in the seccomp sandbox, and maybe rely on AppArmor to
limit the potential damage.
--
Colin Watson [cjwat...@debian.org]
