Chad Wallace writes:
Hi,
> Dear Maintainer,
>
> After upgrading to buster, I failed to get any man pages showing in my
> dwww output. The <pre class="man"> tag is completely empty.
>
> After editing dwww-convert for debugging, I found an error from man:
> man: nroff: Bad system call
>
> Then, I found an example of that on another bug report, which led me to
> add a line to dwww-convert:
>
> ...begin patch
> --- dwww-convert.orig 2019-12-11 14:51:25.131093890 -0800
> +++ dwww-convert 2019-12-11 15:14:02.625790098 -0800
> @@ -246,6 +246,7 @@
> $dir =~ s/\/[^\/]*$//;
> chdir ("$dir/..") or die "Can't chdir!\n";
> $ENV{'MAN_KEEP_FORMATTING'} = 1;
> + $ENV{'MAN_DISABLE_SECCOMP'} = 1;
> my $IN_FH = &OpenPipe("man -EUTF-8 -P/bin/cat -l \"$filename\"
> 2>/dev/null | dwww-txt2html --man --utf8", "r");
> chdir ("/");
> while (<$IN_FH>) {
> ...end patch
>
> That got it working... but I don't really know why. :-)
I cannot reproduce the issue myself, even after downgrading man-db to
2.8.5-2. The bug is almost a year old, can you still reproduce it yourself?
Anyway I am not sure if setting MAN_DISABLE_SECCOMP inside dwww would be
a good idea, as according to NEWS file in man-db sources, it would hide
issues which man-db wants to be notified about:
* Confine most subprocesses that handle untrusted data using
seccomp. This mainly deals with subprocesses that perform
encoding conversions, (de)compressors, groff programs, and a few
other odds and ends. groff programs use a slightly more
permissive filter since they need to create temporary files, so
additional path-based confinement (e.g. using AppArmor) is still
useful.
If this goes wrong, then MAN_DISABLE_SECCOMP=1 can be set in the
environment to disable it, but please report any such problem as a
bug.
I'm adding Collin for confirmation that the above is still valid, and
for a piece of advice what should I do with this bug report.
Regards,
Robert
