Re: The case of the phantom reboot
On Sun, 28 Mar 2021, Stuart Henderson wrote: It is something that could possibly be caused by bad hardware or a glitch in the power feed amongst other options (the latter may affect some machines differently than others).. I've had a string of power "blips" over the last year or so. Oddly enough, the OpenBSD machine always stays up and a Debian machine next to it on the same power strip reboots. I always figured it was due to the superior operating system ;)
Re: Intel wifi ipw showing up but not working
Hi Stefan!
sorry for the even longer delay - but dayjob was demanding, working
even on sunday.
However, if you can read this message, it means that I am connected
through the internal ipw card to WEP WiFi at the first attempt.
Wonderful. Great work, Stefan,
Both patches together applied, of course.
Outside on the balcony... battery works too checked with GNUstep's
battery monitor (written.. by me). Mail written with GNUMail... it got
me some tricks to get GNUstep linking, but also that was solved.
Riccardo
On 2021-03-17 16:09:32 +0100 Stefan Sperling wrote:
My best guess is that because ipw doesn't bother with calling into
the net80211 newstate function, the interface's link state is never
updated and packets cannot flow. With WPA, link state gets updated
as a side-effect of a successful WPA handshake.
Does this fix it?
diff 1ff4cf56fdff3473d72fc4b29d69428c688d47c6 /usr/src
blob - ab16cd51ba6a2efdf89ac588801a1ae2bc714ed5
file + sys/dev/pci/if_ipw.c
--- sys/dev/pci/if_ipw.c
+++ sys/dev/pci/if_ipw.c
@@ -679,7 +679,11 @@ int
ipw_newstate(struct ieee80211com *ic, enum ieee80211_state nstate,
int arg)
{
struct ipw_softc *sc = ic->ic_softc;
+ struct ifnet *ifp = &ic->ic_if;
+ if (LINK_STATE_IS_UP(ifp->if_link_state))
+ ieee80211_set_link_state(ic, LINK_STATE_DOWN);
+
switch (nstate) {
case IEEE80211_S_SCAN:
task_add(systq, &sc->sc_scantask);
@@ -690,6 +694,14 @@ ipw_newstate(struct ieee80211com *ic, enum
ieee80211_s
break;
case IEEE80211_S_RUN:
+ if (!(ic->ic_flags & IEEE80211_F_RSNON)) {
+ /*
+* NB: When RSN is enabled, we defer setting
+* the link up until the port is valid.
+*/
+ ieee80211_set_link_state(ic, LINK_STATE_UP);
+ }
+ break;
case IEEE80211_S_INIT:
case IEEE80211_S_ASSOC:
/* nothing to do */
--
GNUMail running on GNUstep on OpenBSD/i386 Toshiba Tecra
Re: Microphone not working on Gen8 ThinkPad X1 Carbon
Ax0n writes: > I initially noticed it when I hopped in a video room on Discord in Firefox > and folks could see me and I could hear them, but Discord got no audio. It > turns out, nothing gets any audio. sysctl has audio and video recording > enabled, and pledge/unveil has been tweaked just a little for firefox to > pick up the webcam. > > aucat isn't picking up any audio. playing back the WAV I recorded with > aucat or audacity is just silence. Audacity visibly shows very very low > audio levels in the "monitor" VU meter when recording, but no amount of > tinkering with mixerctl, audioctl, or sndioctl seems to make a difference > in the recorded audio -- it's just silent. Audio output is good (videos on > youtube for example) and aucat can play other WAV files just fine. I use > the pianobar package daily to stream Pandora while I work. > > I switched over to the latest snapshot and upgraded packages last night, > and there's no change. There are a number of newer Thinkpads this applies to (my T14s is the same). it is because the microphones are connected differently to previous machines and as such they would require different drivers which do not exist on OpenBSD. It's my understanding that even on some Linux distributions you will find that they are not supported.
Re: The case of the phantom reboot
On 2021-03-28, David Newman wrote: > On 3/28/21 4:58 AM, Kristjan Komloši wrote: > >> On 3/27/21 10:27 PM, David Newman wrote: >>> OpenBSD 6.8 GENERIC#5 i386 >>> >>> One of my systems rebooted at 03:01 local time today. I've seen kernel >>> panics and bad hardware but I've never seen OpenBSD "just reboot" by >>> itself, ever. >>> >>> There's no cron job that would do this. last(1) is no help; it shows the >>> reboot command but not the shutdown that preceded it: >>> >>> root@ns ~ 4# last -f /var/log/wtmp.0 >>> reboot ~ Sat Mar 27 03:01 >>> root ttyp0 192.168.0.132 Wed Mar 24 11:23 - 11:23 >>> (00:00) >>> >>> wtmp.0 begins Wed Mar 24 11:23 2021 >>> root@ns ~ 5# last -f /var/log/wtmp.1 >>> root ttyp0 192.168.0.132 Tue Mar 16 21:30 - 21:30 >>> (00:00) >>> root ttyp0 75.82.86.131 Tue Mar 16 13:14 - 21:30 >>> (08:15) >>> root ttyp0 75.82.86.131 Sun Mar 14 21:20 - 21:29 >>> (00:08) >>> root ttyp0 75.82.86.131 Sat Mar 13 17:42 - 21:13 >>> (03:31) >>> >>> The date gaps seem odd. I've ssh'd into this system multiple times >>> between March 16-27. I don't see other signs of trouble in /var/log. >>> >>> I could use some help in looking for evidence of foul play, or "just" a >>> hardware or software problem. >>> >>> Thanks in advance for further troubleshooting clues. >>> >>> dn >>> >> What kind of a machine is it running on? I remember having reboot >> problems on certain HP and Supermicro servers with hardware watchdogs. > > This is a 10+-year-old Dell 1U server with a 2-GHz Celeron 440, part of > a pair running CARP. Aside from having to replace spinning disks with > SSDs a couple of years ago, they've been rock solid. > > I too have seen issues with Supermicros but that's with other OSs. I've > never had a spontaneous reboot, on this system, and am concerned from > the wtmp stuff above that this *may* have been triggered externally. I > could use some clues in other things to check. Thanks. > > dn > > The "reboot" wtmp entry is written by init(8). It is something that could possibly be caused by bad hardware or a glitch in the power feed amongst other options (the latter may affect some machines differently than others).. Perhaps it's worth enabling accounting in rc.conf.local to see if you can figure out if any commands are executed around that time if it happens again.
Re: Intel wifi ipw showing up but not working
On Sun, Mar 28, 2021 at 05:58:31PM +0200, Riccardo Mottola wrote: > However, if you can read this message, it means that I am connected through > the internal ipw card to WEP WiFi at the first attempt. Wonderful. Great > work, Stefan, Great, thank you for confirming! I have committed the fix. Glad to know that old hardware and drivers like this are still useful. Cheers, Stefan
Microphone not working on Gen8 ThinkPad X1 Carbon
I initially noticed it when I hopped in a video room on Discord in Firefox and folks could see me and I could hear them, but Discord got no audio. It turns out, nothing gets any audio. sysctl has audio and video recording enabled, and pledge/unveil has been tweaked just a little for firefox to pick up the webcam. aucat isn't picking up any audio. playing back the WAV I recorded with aucat or audacity is just silence. Audacity visibly shows very very low audio levels in the "monitor" VU meter when recording, but no amount of tinkering with mixerctl, audioctl, or sndioctl seems to make a difference in the recorded audio -- it's just silent. Audio output is good (videos on youtube for example) and aucat can play other WAV files just fine. I use the pianobar package daily to stream Pandora while I work. I switched over to the latest snapshot and upgraded packages last night, and there's no change. Relevant output follows: OpenBSD 6.9-beta (GENERIC.MP) #431: Sat Mar 27 01:45:57 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16774819840 (15997MB) avail mem = 16251035648 (15498MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.2 @ 0x6cbac000 (70 entries) bios0: vendor LENOVO version "N2WET26W (1.16 )" date 01/21/2021 bios0: LENOVO 20U9S1QP00 acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 SSDT HPET APIC MCFG ECDT SSDT SSDT SSDT NHLT BOOT SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB DMAR ASF! UEFI FPDT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 7903.91 MHz, 06-8e-0c cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1797.69 MHz, 06-8e-0c cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz, 1795.82 MHz, 06-8e-0c cpu4: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,API
Re: The case of the phantom reboot
On 3/28/21 4:58 AM, Kristjan Komloši wrote: > On 3/27/21 10:27 PM, David Newman wrote: >> OpenBSD 6.8 GENERIC#5 i386 >> >> One of my systems rebooted at 03:01 local time today. I've seen kernel >> panics and bad hardware but I've never seen OpenBSD "just reboot" by >> itself, ever. >> >> There's no cron job that would do this. last(1) is no help; it shows the >> reboot command but not the shutdown that preceded it: >> >> root@ns ~ 4# last -f /var/log/wtmp.0 >> reboot ~ Sat Mar 27 03:01 >> root ttyp0 192.168.0.132 Wed Mar 24 11:23 - 11:23 >> (00:00) >> >> wtmp.0 begins Wed Mar 24 11:23 2021 >> root@ns ~ 5# last -f /var/log/wtmp.1 >> root ttyp0 192.168.0.132 Tue Mar 16 21:30 - 21:30 >> (00:00) >> root ttyp0 75.82.86.131 Tue Mar 16 13:14 - 21:30 >> (08:15) >> root ttyp0 75.82.86.131 Sun Mar 14 21:20 - 21:29 >> (00:08) >> root ttyp0 75.82.86.131 Sat Mar 13 17:42 - 21:13 >> (03:31) >> >> The date gaps seem odd. I've ssh'd into this system multiple times >> between March 16-27. I don't see other signs of trouble in /var/log. >> >> I could use some help in looking for evidence of foul play, or "just" a >> hardware or software problem. >> >> Thanks in advance for further troubleshooting clues. >> >> dn >> > What kind of a machine is it running on? I remember having reboot > problems on certain HP and Supermicro servers with hardware watchdogs. This is a 10+-year-old Dell 1U server with a 2-GHz Celeron 440, part of a pair running CARP. Aside from having to replace spinning disks with SSDs a couple of years ago, they've been rock solid. I too have seen issues with Supermicros but that's with other OSs. I've never had a spontaneous reboot, on this system, and am concerned from the wtmp stuff above that this *may* have been triggered externally. I could use some clues in other things to check. Thanks. dn
Re: cgit about-filter in chroot (httpd + slowcgi)
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
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 < my-cgit-filter.c
#include
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:
StartEnd Type Open Ref GrpRef Name
05196d856000 05196d87b000 dlib 10 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 :)
Re: cgit about-filter in chroot (httpd + slowcgi)
On 2021-03-28 18:14, Omar Polo wrote:
Paul W. Rankin 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
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?
Re: cgit about-filter in chroot (httpd + slowcgi)
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?
Re: The case of the phantom reboot
On 3/27/21 10:27 PM, David Newman wrote: OpenBSD 6.8 GENERIC#5 i386 One of my systems rebooted at 03:01 local time today. I've seen kernel panics and bad hardware but I've never seen OpenBSD "just reboot" by itself, ever. There's no cron job that would do this. last(1) is no help; it shows the reboot command but not the shutdown that preceded it: root@ns ~ 4# last -f /var/log/wtmp.0 reboot~ Sat Mar 27 03:01 root ttyp0192.168.0.132Wed Mar 24 11:23 - 11:23 (00:00) wtmp.0 begins Wed Mar 24 11:23 2021 root@ns ~ 5# last -f /var/log/wtmp.1 root ttyp0192.168.0.132Tue Mar 16 21:30 - 21:30 (00:00) root ttyp075.82.86.131 Tue Mar 16 13:14 - 21:30 (08:15) root ttyp075.82.86.131 Sun Mar 14 21:20 - 21:29 (00:08) root ttyp075.82.86.131 Sat Mar 13 17:42 - 21:13 (03:31) The date gaps seem odd. I've ssh'd into this system multiple times between March 16-27. I don't see other signs of trouble in /var/log. I could use some help in looking for evidence of foul play, or "just" a hardware or software problem. Thanks in advance for further troubleshooting clues. dn What kind of a machine is it running on? I remember having reboot problems on certain HP and Supermicro servers with hardware watchdogs. -- Kristjan Komloši
Re: cgit about-filter in chroot (httpd + slowcgi)
On 2021-03-28, Kristaps Dzonsons wrote:
$ cat < my-cgit-filter.c
#include
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.
Re: cgit about-filter in chroot (httpd + slowcgi)
$ cat < my-cgit-filter.c
#include
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).
Re: cgit about-filter in chroot (httpd + slowcgi)
Paul W. Rankin 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
>>> 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 < my-cgit-filter.c
>> #include
>> 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:
>> StartEnd Type Open Ref GrpRef Name
>> 05196d856000 05196d87b000 dlib 10 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 :)
Re: cgit about-filter in chroot (httpd + slowcgi)
Paul W. Rankin writes:
> On 2021-03-28 18:14, Omar Polo wrote:
>> Paul W. Rankin 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
> 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 < my-cgit-filter.c
#include
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:
StartEnd Type Open Ref GrpRef Name
05196d856000 05196d87b000 dlib 10 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);
