cgit about-filter in chroot (httpd + slowcgi)

[Paul W. Rankin]

Hello,

I'm running cgit with httpd + slowcgi and can't seem to get the
about-filter to work. Both httpd and slowcgi run in the default chroot
of /var/www.

I've compiled lowdown with "-static -pie" to /var/www/bin/lowdown
(chroot /bin/lowdown) with permissions:

     -rwxr-xr-x  1 root  bin  1325512 Mar  4 01:38 /var/www/bin/lowdown

In my cgitrc (cgit.conf):

     about-filter=/bin/lowdown
     readme=:README.md

However, upon visiting an About page of a repo that includes a
README.md, I get only a blank page and the following is logged in
error.log:

     lowdown: README.md: No such file or directory

Here's the cgit server section in httpd.conf:

        server "git.bydasein.com" {
                        listen on * port 80
                        listen on * tls port 443
                        root "/cgi-bin/cgit.cgi"
                        tls {
                                        certificate "/etc/ssl/bydasein.com.fullchain.pem"
                                        key "/etc/ssl/private/bydasein.com.key"
                        }
                        location "/.well-known/acme-challenge/*" {
                                        root "/acme"
                                        request strip 2
                        }
                        location "/robots.txt" {
                                        root "/htdocs/git.bydasein.com"
                                        no fastcgi
                        }
                        location "/favicon.ico" {
                                        root "/htdocs/git.bydasein.com"
                                        no fastcgi
                        }
                        location "/cgit.css" {
                                        root "/htdocs/git.bydasein.com"
                                        no fastcgi
                        }
                        location "/custom.css" {
                                        root "/htdocs/git.bydasein.com"
                                        no fastcgi
                        }
                        fastcgi {
                                        socket "/run/slowcgi.sock"
                                        param CGIT_CONFIG "/conf/cgit.conf"
                        }
        }

I'm pretty sure I can have this work if I disable the chroot in httpd
and/or slowcgi, but I'd prefer a solution that doesn't require that.

Does anyone have any ideas? Has anyone managed to get cgit running on
OpenBSD using httpd + slowcgi with chroot enabled?

Thanks for your time :)

--
Paul W. Rankin
https://bydasein.com

The single best thing you can do for the world is delete your social
media accounts.

[Paul W. Rankin]

On 2021-03-28 15:37, Paul W. Rankin wrote:

> I'm running cgit with httpd + slowcgi and can't seem to get the
> about-filter to work. Both httpd and slowcgi run in the default chroot
> of /var/www.
>
> I've compiled lowdown with "-static -pie" to /var/www/bin/lowdown
> (chroot /bin/lowdown) with permissions:
>
>     -rwxr-xr-x  1 root  bin  1325512 Mar  4 01:38 /var/www/bin/lowdown
>
> In my cgitrc (cgit.conf):
>
>     about-filter=/bin/lowdown
>     readme=:README.md
>
> However, upon visiting an About page of a repo that includes a
> README.md, I get only a blank page and the following is logged in
> error.log:
>
>     lowdown: README.md: No such file or directory

Okay I figured this out, but the solution raises a troubling question...

The cgit about-filter doesn't want an executable to do e.g. the Markdown
conversation, rather it wants a script that will return the command to
perform this, e.g.:

     #!/bin/sh
     case "$1" in
     (*.md)              exec /bin/lowdown ;;
     (*)                 exit ;;
     esac

This works, i.e. README.md files are converted to HTML, but this
requires copying the sh binary into /var/www/bin, which is the troubling
part.

Is this an acceptable thing to do, security-wise?

[Paul W. Rankin]

On 2021-03-28 18:14, Omar Polo wrote:

> Paul W. Rankin <[hidden email]> writes:
>> The cgit about-filter doesn't want an executable to do e.g. the
>> Markdown conversation, rather it wants a script that will return the
>> command to perform this, e.g.:
>>
>>     #!/bin/sh
>>     case "$1" in
>>     (*.md)              exec /bin/lowdown ;;
>>     (*)                 exit ;;
>>     esac
>>
>> This works, i.e. README.md files are converted to HTML, but this
>> requires copying the sh binary into /var/www/bin, which is the
>> troubling part.
>>
>> Is this an acceptable thing to do, security-wise?
>
> I don't know almost anything about cgit, but if that's really the
> problem you could statically-link a program that does the above (just a
> call to execl("/bin/lowdown", NULL); may be enough) and use that.

Thanks Omar, I like this approach! I'm pretty green to C so this is what
I have (which doesn't work):

        #include <unistd.h>
        int main(void) {
                execl("/bin/lowdown", NULL);
        }

There is no HTML render but at least no errors, but cgit expects the
resulting HTML printed to STDOUT, so I wonder whether this requires a
return?

[Omar Polo-3]

Paul W. Rankin <[hidden email]> writes:

> On 2021-03-28 18:14, Omar Polo wrote:
>> Paul W. Rankin <[hidden email]> writes:
>>> The cgit about-filter doesn't want an executable to do e.g. the
>>> Markdown conversation, rather it wants a script that will return the
>>> command to perform this, e.g.:
>>>     #!/bin/sh
>>>     case "$1" in
>>>     (*.md)              exec /bin/lowdown ;;
>>>     (*)                 exit ;;
>>>     esac
>>> This works, i.e. README.md files are converted to HTML, but this
>>> requires copying the sh binary into /var/www/bin, which is the
>>> troubling part.
>>> Is this an acceptable thing to do, security-wise?
>> I don't know almost anything about cgit, but if that's really the
>> problem you could statically-link a program that does the above (just a
>> call to execl("/bin/lowdown", NULL); may be enough) and use that.
>
> Thanks Omar, I like this approach! I'm pretty green to C so this is
> what I have (which doesn't work):
>
> #include <unistd.h>
> int main(void) {
> execl("/bin/lowdown", NULL);
> }
>
> There is no HTML render but at least no errors, but cgit expects the
> resulting HTML printed to STDOUT, so I wonder whether this requires a
> return?

Assuming that the shell script you posted actually works yes, that
snippet (with a small tweak[0]) should work.  Make sure it's statically
linked.

For reference, here's how I would do it

$ cat <<EOF > my-cgit-filter.c
#include <unistd.h>

int
main(void)
{
        execl("/bin/lowdown", "lowdown", NULL);
        return 1;
}
EOF
$ cc my-cgit-filter.c -o my-cgit-filter.c -static
$ # check that it's actually statically linked
$ ldd my-cgit-filter
my-cgit-filter:
        Start            End              Type  Open Ref GrpRef Name
        000005196d856000 000005196d87b000 dlib  1    0   0      /tmp/my-cgit-filter

--

Cheers


[0]: if you compile your snippet, clang should warning about a missing
     sentinel, something along the lines of

     > warning: not enough variable arguments in 'execl' declaration to fit a
     > sentinel [-Wsentinel]
     >   execl("/bin/lowdown", NULL);

     which should suggest the use of
     >   execl("/bin/lowdown", "lowdown", NULL);

[Paul W. Rankin]

On 2021-03-28 18:56, Omar Polo wrote:

>> Thanks Omar, I like this approach! I'm pretty green to C so this is
>> what I have (which doesn't work):
>>
>> #include <unistd.h>
>> int main(void) {
>> execl("/bin/lowdown", NULL);
>> }
>>
>> There is no HTML render but at least no errors, but cgit expects the
>> resulting HTML printed to STDOUT, so I wonder whether this requires a
>> return?
>
> Assuming that the shell script you posted actually works yes, that
> snippet (with a small tweak[0]) should work.  Make sure it's statically
> linked.
>
> For reference, here's how I would do it
>
> $ cat <<EOF > my-cgit-filter.c
> #include <unistd.h>
>
> int
> main(void)
> {
>         execl("/bin/lowdown", "lowdown", NULL);
> return 1;
> }
> EOF
> $ cc my-cgit-filter.c -o my-cgit-filter.c -static
> $ # check that it's actually statically linked
> $ ldd my-cgit-filter
> my-cgit-filter:
>         Start            End              Type  Open Ref GrpRef Name
>         000005196d856000 000005196d87b000 dlib  1    0   0
> /tmp/my-cgit-filter
>
> [0]: if you compile your snippet, clang should warning about a missing
>      sentinel, something along the lines of
>
>      > warning: not enough variable arguments in 'execl' declaration to
> fit a
>      > sentinel [-Wsentinel]
>      >   execl("/bin/lowdown", NULL);
>
>      which should suggest the use of
>      >   execl("/bin/lowdown", "lowdown", NULL);

Thank you so much Omar! Making the sentinel change solved it :)

[Omar Polo-3]

Paul W. Rankin <[hidden email]> writes:

> On 2021-03-28 18:56, Omar Polo wrote:
>>> Thanks Omar, I like this approach! I'm pretty green to C so this is
>>> what I have (which doesn't work):
>>> #include <unistd.h>
>>> int main(void) {
>>> execl("/bin/lowdown", NULL);
>>> }
>>> There is no HTML render but at least no errors, but cgit expects
>>> the
>>> resulting HTML printed to STDOUT, so I wonder whether this requires a
>>> return?
>> Assuming that the shell script you posted actually works yes, that
>> snippet (with a small tweak[0]) should work.  Make sure it's statically
>> linked.
>> For reference, here's how I would do it
>> $ cat <<EOF > my-cgit-filter.c
>> #include <unistd.h>
>> int
>> main(void)
>> {
>>         execl("/bin/lowdown", "lowdown", NULL);
>> return 1;
>> }
>> EOF
>> $ cc my-cgit-filter.c -o my-cgit-filter.c -static
>> $ # check that it's actually statically linked
>> $ ldd my-cgit-filter
>> my-cgit-filter:
>>         Start            End              Type  Open Ref GrpRef Name
>>         000005196d856000 000005196d87b000 dlib  1    0   0
>> /tmp/my-cgit-filter
>> [0]: if you compile your snippet, clang should warning about a
>> missing
>>      sentinel, something along the lines of
>>      > warning: not enough variable arguments in 'execl' declaration
>> to fit a
>>      > sentinel [-Wsentinel]
>>      >   execl("/bin/lowdown", NULL);
>>      which should suggest the use of
>>      >   execl("/bin/lowdown", "lowdown", NULL);
>
> Thank you so much Omar! Making the sentinel change solved it :)

Glad it worked, and apologies for not writing the execl call correctly
the first time I mentioned it :)

[Kristaps Dzonsons]

>>> $ cat <<EOF > my-cgit-filter.c
>>> #include <unistd.h>
>>> int
>>> main(void)
>>> {
>>>          execl("/bin/lowdown", "lowdown", NULL);
>>> return 1;
>>> }
>>> EOF
>>> $ cc my-cgit-filter.c -o my-cgit-filter.c -static

Instead of downloading, recompiling, and installing lowdown; then
building and installing a program that execs the downloaded lowdown; why
don't you cut out the first step and call through to the C API installed
with the lowdown port?  There's a full example in the EXAMPLES section
of lowdown_file(3).

[Stuart Henderson]

On 2021-03-28, Kristaps Dzonsons <[hidden email]> wrote:
>>>> $ cat <<EOF > my-cgit-filter.c
>>>> #include <unistd.h>
>>>> int
>>>> main(void)
>>>> {
>>>>          execl("/bin/lowdown", "lowdown", NULL);
>>>> return 1;
>>>> }
>>>> EOF

So essentially all this is doing is stripping off the command line
arguments.

>>>> $ cc my-cgit-filter.c -o my-cgit-filter.c -static

output file overwrites the input file here ^^

> Instead of downloading, recompiling, and installing lowdown; then
> building and installing a program that execs the downloaded lowdown; why
> don't you cut out the first step and call through to the C API installed
> with the lowdown port?  There's a full example in the EXAMPLES section
> of lowdown_file(3).

Alternatively you can copy the lowdown binary from the package, along
with libc/libm/ld.so, into the chroot (which can be done from /etc/rc.local).
Then there's no need to recompile things for future lowdown updates.

[Paul W. Rankin]

On 2021-03-28 19:33, Kristaps Dzonsons wrote:
>
> Instead of downloading, recompiling, and installing lowdown; then
> building and installing a program that execs the downloaded lowdown;
> why don't you cut out the first step and call through to the C API
> installed with the lowdown port?  There's a full example in the
> EXAMPLES section of lowdown_file(3).

Sorry Kristaps I didn't see this because I was not previous subscribed
to the list. Thanks for pointing me in this direction, it does look like
the optimal approach. At my current point in The C Programming Language
book the example still looks like Greek to me (I'm not up to structs or
pointers) but one day...

Thanks!