Re: smtpd warn: not enough disk space
On 2024-07-05 05:19:01 +0200, Christian Schulte wrote: > I have never seen an application performing such kind of checks. Sendmail had a knob to refuse mail at a certain CPU load, on the assumption that if a system was "too busy" it's in a bad state and accepting mail would only make things worse. Also rogue(6) had CPU checks, apparently they wanted to stop any rogue processes when the system load got too high--maybe real work was being done? Speaking of not checking the CPU, I have an amusing story of what a dual-processor Linux box did at a CPU load of 5,000, something something sending the wrong bytes to the wrong file descriptors, thus corrupting payment transactions for a small internet retailer. For application-specific filesystem checks I don't recall any off the top of my head, but I tend to have monitoring send dire alerts when the disk usage hits 90% (or less, if you want more breathing room to figure out what is wrong, who to notify, them to act, etc) so would never have seen anything that triggers at 5% free or whatever. > If there is not enough space, write would fail anyway. Or the filesystem gets somewhat looped after being run at 100% full for too long. Granted, that was Windows, and we did warn the user not to do that, but they did, and then when a nice Windows admin tried to backup the 500G disk, it filled up a 3T disk and wanted more. Who knows what breaks when a stray dd(1) or package update or whatever eats too much of the remaining space. Not breaking randomly is probably a design goal of a SMTP server that tries to guarantee delivery? You could fiddle with the percentage, or remove the code, but I'm going to guess that most everyone else keeps their mail partitions not so full.
Re: Awk split()/array bug in 7.5
On 2024-05-30 14:56:50 -0600, Todd C. Miller wrote: > This is not a bug. An awk associative array is effectively a hash > table so when you iterate over it like this you are not guaranteed > to get things in any particular order. In fact, our awk, mawk and > gawk all produce different output when given that snippet. Also, various languages that used to use predictable hash orders now randomize the key order to avoid Algorithmic Complexity Attacks that may allow an attacker to supply input crafted to consume lots of CPU memory or both. http://man.openbsd.org/man1/perlsec.1#Algorithmic_Complexity_Attacks
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
TL;DR it's TERMINFO related or when ~/.terminfo exists and no TERM file
exists therein. Also trying to read "none" (or maybe also "none.db" when
the TERMINFO thing happens) from the current working directory might not
be a good idea, if an attacker can put naughty things into either of
those files and a sh or ksh or whatever is run in a suitable directory?
On 2024-04-08 15:30:11 +, Jeremy Mates wrote:
> 79510 ksh NAMI "none.db"
> 79510 ksh RET open -1 errno 2 No such file or directory
> 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x3)
> 79510 ksh RET mprotect 0
> 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x1)
> 79510 ksh RET mprotect 0
> 79510 ksh CALL open(0x744b97b1eed0,0x1)
> 79510 ksh NAMI "none"
> 79510 ksh RET open -1 errno 2 No such file or directory
> 79510 ksh CALL sendsyslog(0x744b97b1c140,35,0<>)
> 79510 ksh GIO fd -1 wrote 35 bytes
>"<10>ksh: vfprintf %s NULL in "%.*s""
There are two instances of "none" in the ncurses code; setting TERMPATH
to "" and recompiling results in hits for ".db" in my custom
(and very incomplete) ~/.terminfo directory where to tigger this error
~/.terminfo/r/rxvt-unicode-256color does not exist, but that file does
exist in /usr/share/terminfo (and also /usr/local/share/terminfo but
that looks to be last in the list and is not consulted).
62759 rogueCALL fcntl(1,F_ISATTY)
62759 rogueRET fcntl 1
... (various kbind calls removed)
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL stat(0xbd1b58b8700,0xbd1b5893c00)
62759 rogueNAMI "/home/jmates/.terminfo"
62759 rogueSTRU struct stat { dev=1035, ino=9504797, mode=drwx--
, nlink=5, uid=1000<"jmates">, gid=1000<"jmates">, rdev=37949602,
atime=1664240431<"Sep 27 01:00:31 2022">.902138053, mtime=1713140694<"Apr 15
00:24:54 2024">.605888358, ctime=1713140694<"Apr 15 00:24:54 2024">.605888358,
size=512, blocks=8, blksize=32768, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b8717,0xbd1b5893c80)
62759 rogueNAMI "/usr/share/terminfo"
62759 rogueSTRU struct stat { dev=1029, ino=77975, mode=drwxr-xr-x ,
nlink=44, uid=0<"root">, gid=0<"wheel">, rdev=347089, atime=1710969405<"Mar 20
21:16:45 2024">, mtime=1710969405<"Mar 20 21:16:45 2024">,
ctime=1712330397<"Apr 5 15:19:57 2024">.280403075, size=1024, blocks=4,
blksize=16384, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b872b,0xbd1b5893d00)
62759 rogueNAMI "/usr/local/share/terminfo"
62759 rogueSTRU struct stat { dev=1031, ino=1398, mode=drwxr-xr-x ,
nlink=4, uid=0<"root">, gid=0<"wheel">, rdev=27828, atime=1664242579<"Sep 27
01:36:19 2022">.894146606, mtime=1699341912<"Nov 7 07:25:12 2023">.868578098,
ctime=1699341912<"Nov 7 07:25:12 2023">.868578098, size=512, blocks=4,
blksize=16384, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
62759 rogueCALL stat(0xbd1b58b8759,0xbd1b5893d80)
62759 rogueNAMI ""
62759 rogueRET stat -1 errno 2 No such file or directory
...
62759 rogueCALL stat(0xbd1b58b8700,0x798526d4f508)
62759 rogueNAMI "/home/jmates/.terminfo"
62759 rogueSTRU struct stat { dev=1035, ino=9504797, mode=drwx--
, nlink=5, uid=1000<"jmates">, gid=1000<"jmates">, rdev=37949602,
atime=1664240431<"Sep 27 01:00:31 2022">.902138053, mtime=1713140694<"Apr 15
00:24:54 2024">.605888358, ctime=1713140694<"Apr 15 00:24:54 2024">.605888358,
size=512, blocks=8, blksize=32768, flags=0x0, gen=0x0 }
62759 rogueRET stat 0
...
62759 rogueCALL access(0x798526d57640,0x4)
62759 rogueNAMI "/home/jmates/.terminfo/r/rxvt-unicode-256color"
62759 rogueRET access -1 errno 2 No such file or directory
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL issetugid()
62759 rogueRET issetugid 0
...
62759 rogueCALL open(0x798526d4b960,0x1)
62759 rogueNAMI ".db"
62759 rogueRET open -1 errno 2 No such file or directory
62759 rog
Re: 7.5 /var/log/messages - vfprintf %s NULL in "%.*s"
Given logger foo;xterm -tn xterm-256color -e ktrace -di /bin/ksh the log message 'ksh: vfprintf %s NULL in "%.*s"' appears when ~/.terminfo/x/xterm/xterm-256color does not exist. The log message no longer appears after running cp /usr/share/terminfo/x/xterm-256color ~/.terminfo/x/ and comes back after deleting the ~/.terminfo/x/xterm-256color file. The kdump when the log message happens runs along the lines of: 79510 ksh CALL access(0x744b97b272e0,0x4) 79510 ksh NAMI "/home/jmates/.terminfo/x/xterm-256color" 79510 ksh RET access -1 errno 2 No such file or directory 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL issetugid() 79510 ksh RET issetugid 0 79510 ksh CALL open(0x744b97b1b600,0x1) 79510 ksh NAMI "none.db" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x3) 79510 ksh RET mprotect 0 79510 ksh CALL mprotect(0x4e89f6c1000,0x1000,0x1) 79510 ksh RET mprotect 0 79510 ksh CALL open(0x744b97b1eed0,0x1) 79510 ksh NAMI "none" 79510 ksh RET open -1 errno 2 No such file or directory 79510 ksh CALL sendsyslog(0x744b97b1c140,35,0<>) 79510 ksh GIO fd -1 wrote 35 bytes "<10>ksh: vfprintf %s NULL in "%.*s"" 79510 ksh RET sendsyslog 0
Re: Bash instead of ksh
On 2024-04-02 15:34:56 -0400, Steve Litt wrote: > If you mean a shell with which to run shellscripts, I wouldn't do that. > Inside bash is a big old messy attack surface. There was a bash exploit > several years ago (was it heartbleed?) that caused me to change all > shellscript shebangs to #!/bin/sh. shellshock, or lol free root access because the (too many?) lines of code in bash got hooked up to lots of stuff and selinux was walzed by, etc
lilypond PDF builds broken in OpenBSD 7.4 following ghostscript-10.02.0->10.02.1 ?
Nov 12 19:41:30 gear pkg_add: Added firefox-119.0->119.0.1
Nov 12 19:41:55 gear pkg_add: Added ghostscript-10.02.0->10.02.1
PDF builds fail, can someone confirm this isn't my system being wacky?
$ ls test.*
test.ly
$ cat test.ly
\version "2.22.2"
\score {
{ \new Staff { e4 e e c1 } }
\layout {}
\midi {}
}
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Interpreting music...
MIDI output to `test.midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Converting to `test.pdf'...
warning: `(gs -q -dNODISPLAY -dNOSAFER -dNOPAUSE -dBATCH
-dAutoRotatePages=/None -dPrinted=false /tmp/lilypond-tmp-3901926)' failed (256)
fatal error: failed files: "test.ly"
If the "build PDF" bit is disabled, then no error:
$ ed test.ly
84
/lay
\layout {}
s/^/%
% \layout {}
wq
85
$ /usr/local/bin/lilypond test.ly
GNU LilyPond 2.22.2
Processing `test.ly'
Parsing...
Interpreting music...
MIDI output to `test.midi'...
Success: compilation successfully completed
$ ls test.*
test.ly test.midi
ktrace -di shows lilypond and gs chatting but nothing clear as to what or why
there was an error:
18383 gs GIO fd 2 wrote 7 bytes
"10.02.1"
42762 lilypond STRU struct pollfd [2] { fd=9,
events=0x19, revents=0<> } { fd=11, events=0x19,
revents=0x1 }
18383 gs RET write 7
42762 lilypond RET poll 1
18383 gs CALL write(2,0x7365ef51ef40,0x2)
42762 lilypond CALL read(11,0x758d0fb810a0,0x1000)
18383 gs GIO fd 2 wrote 2 bytes
": "
42762 lilypond GIO fd 11 read 25 bytes
"GPL Ghostscript 10.02.1: "
18383 gs RET write 2
42762 lilypond RET read 25/0x19
18383 gs CALL write(2,0x7365ef51ef40,0x21)
42762 lilypond CALL poll(0x758d0fb82190,2,INFTIM)
18383 gs GIO fd 2 wrote 33 bytes
"Unrecoverable error, exit code 1
"
rare vi crash
The crash happens maybe a few times per year, and eventually resolved to
the following guard with the error "Tailq for buffer \xc8 is empty", but
I'm not sure how \xc8 is getting there, maybe I'm lingering on a control
key or something whilst flailing at the keyboard. Some idle testing with
"p did not reproduce the issue; the buffer
needs to be not empty, but not have a queue??
--- usr.bin/vi/common/put.c
+++ usr.bin/vi/common/put.c
@@ -57,6 +57,10 @@ put(SCR *sp, CB *cbp, CHAR_T *namep, MARK *cp, MARK *rp, int
append)
}
}
}
+ if (TAILQ_EMPTY(>textq)) {
+ msgq(sp, M_ERR, "Tailq for buffer %s is empty", KEY_NAME(sp,
name));
+ return (1);
+ }
tp = TAILQ_FIRST(>textq);
/*
Re: vi - inability to search backwards for ?
On 2023-05-13 20:53:01 -0700, Kastus Shchuka wrote: > Have you tried using ?[\?] in extended mode? It works for me. Yes, that's already in the blog posting and is a bit more to type and remember than a ?\?
Re: vi - inability to search backwards for ?
On 2023-05-13 10:26:42 +0200, Andreas Kusalananda Kähäri wrote: > I'm assuming this is with the "extended" option set in vi, right? Yes.
vi - inability to search backwards for ?
A search for /\/ is okay; this discards the \ and searches for "/"
A search for ?\? is not okay; this discards the \ and searches for "?"
which is an invalid regular expression, "RE error: repetition-operator
operand invalid".
A problematic bare leading ? on a backwards search can be escaped by
the following, though I'm not sure if that's an ideal fix. Thoughts?
--- search.c.orig Sat Dec 10 08:06:18 2022
+++ search.cFri May 12 23:05:31 2023
@@ -120,6 +120,12 @@
plen = t - ptrn;
}
+ if (delim == '?' && *ptrn == '?') {
+ ptrn--;
+ plen++;
+ *ptrn = '\\';
+ }
+
/* Compile the RE. */
if (re_compile(sp, ptrn, plen, >re, >re_len, >re_c,
RE_C_SEARCH |
Re: ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
On 2022-12-12 10:01:05 +0100, Claudio Jeker wrote: > I think this is the wrong way around. The callers need to be fixed to pass > a blocking stdin to programs since that is what every unix utility > expects. What you propose it to fix every unix utility to have such a check > at the start of main. Sorry but no. Ah, as it turns out the non-blocking of stdin was to workaround a bug in https://github.com/osa1/tiny/issues/269 https://github.com/microsoft/WSL/issues/3507 so I'll try to convince the tiny folks to only do that on WSL.
ex/vi 100% CPU when STDIN_FILENO set to O_NONBLOCK
...
42136 ex RET read -1 errno 35 Resource temporarily unavailable
42136 ex CALL read(0,0x3d94b585400,0xff)
42136 ex RET read -1 errno 35 Resource temporarily unavailable
42136 ex CALL read(0,0x3d94b585400,0xff)
...
this condition can be reproduced with:
#include
#include
#include
#include
#include
#define TARGET_FD STDIN_FILENO
int main(int argc, char *argv[]) {
int flags, status;
pid_t pid;
pid = fork();
if (pid < 0) err(1, "fork failed");
if (pid == 0) {
flags = fcntl(TARGET_FD, F_GETFL, 0);
if (flags == -1) err(1, "fcntl getfl failed");
flags |= O_NONBLOCK;
flags = fcntl(TARGET_FD, F_SETFL, flags);
if (flags == -1) err(1, "fcntl setfl failed");
argv++;
execvp(*argv, argv);
err(1, "execvp failed");
}
wait();
exit(0);
}
and then running whatever-the-above-was-compiled-to as
./whatever /usr/bin/ex
or also under modern code that for some reason sets O_NONBLOCK and
forgets to turn it off when calling out to an editor, hypothetically
https://github.com/osa1/tiny
and likely other, similar programs. Probably, O_NONBLOCK should be
disabled on STDIN_FILENO before calling out to unknown programs.
Probably, vi should be patched to not eat CPU when the previous case is
not handled.
Thoughts?
diff --git usr.bin/vi/cl/cl_main.c usr.bin/vi/cl/cl_main.c
index 33614c99594..f87a04cad8b 100644
--- usr.bin/vi/cl/cl_main.c
+++ usr.bin/vi/cl/cl_main.c
@@ -54,7 +54,7 @@ main(int argc, char *argv[])
CL_PRIVATE *clp;
GS *gp;
size_t rows, cols;
- int rval;
+ int flags, oflags, rval;
char *ttype;
/* Create and initialize the global structure. */
@@ -89,6 +89,14 @@ main(int argc, char *argv[])
/* Ex wants stdout to be buffered. */
(void)setvbuf(stdout, NULL, _IOFBF, 0);
+ /* Ensure blocking I/O to avoid 100% CPU on EAGAIN */
+ if ((flags = fcntl(STDIN_FILENO, F_GETFL, 0)) == -1)
+ exit (1);
+ oflags = flags;
+ flags &= ~O_NONBLOCK;
+ if (fcntl(STDIN_FILENO, F_SETFL, flags) == -1)
+ exit (1);
+
/* Start catching signals. */
if (sig_init(gp, NULL))
exit (1);
@@ -102,6 +110,9 @@ main(int argc, char *argv[])
/* Clean up the terminal. */
(void)cl_quit(gp);
+ /* Restore flags */
+ fcntl(STDIN_FILENO, F_SETFL, oflags);
+
/*
* XXX
* Reset the O_MESG option.
Re: embarrassing mail problem
On Wed, Oct 05, 2022 at 10:04:36PM +0100, Steve Fairhead wrote: > For Sendmail, the error is "TLS handshake failed"; for smtpd, it's > "Network error on destination MXs". one "fix" would be to disable TLS for the domains in question, which at least would let the mail go through until the encryption can be set aright, perhaps with an access map entry along the lines of Try_TLS:badhost.example.com NO
