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. |
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? |
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? |
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); |
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 :) |
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 :) |
>>> $ 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). |
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. |
In reply to this post by Kristaps Dzonsons
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! |
Free forum by Nabble | Edit this page |