public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Make End-Of-Recovery error less scary
29+ messages / 9 participants
[nested] [flat]
* [PATCH] Make End-Of-Recovery error less scary
@ 2022-07-07 02:51 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 29+ messages in thread
From: Kyotaro Horiguchi @ 2022-07-07 02:51 UTC (permalink / raw)
When recovery in any type ends, we see a bit scary error message like
"invalid record length" that suggests something serious is
happening. Actually if recovery meets a record with length = 0, that
usually means it finished applying all available WAL records.
Make this message less scary as "reached end of WAL". Instead, raise
the error level for other kind of WAL failure to WARNING.
---
src/backend/access/transam/xlogreader.c | 134 +++++++++++++++++-----
src/backend/access/transam/xlogrecovery.c | 95 +++++++++++----
src/backend/replication/walreceiver.c | 7 +-
src/bin/pg_waldump/pg_waldump.c | 13 ++-
src/include/access/xlogreader.h | 1 +
src/test/recovery/t/011_crash_recovery.pl | 106 +++++++++++++++++
6 files changed, 298 insertions(+), 58 deletions(-)
diff --git a/src/backend/access/transam/xlogreader.c b/src/backend/access/transam/xlogreader.c
index 050d2f424e4..9b8f29d0ad0 100644
--- a/src/backend/access/transam/xlogreader.c
+++ b/src/backend/access/transam/xlogreader.c
@@ -48,6 +48,8 @@ static int ReadPageInternal(XLogReaderState *state, XLogRecPtr pageptr,
int reqLen);
static void XLogReaderInvalReadState(XLogReaderState *state);
static XLogPageReadResult XLogDecodeNextRecord(XLogReaderState *state, bool non_blocking);
+static bool ValidXLogRecordLength(XLogReaderState *state, XLogRecPtr RecPtr,
+ XLogRecord *record);
static bool ValidXLogRecordHeader(XLogReaderState *state, XLogRecPtr RecPtr,
XLogRecPtr PrevRecPtr, XLogRecord *record, bool randAccess);
static bool ValidXLogRecord(XLogReaderState *state, XLogRecord *record,
@@ -149,6 +151,7 @@ XLogReaderAllocate(int wal_segment_size, const char *waldir,
pfree(state);
return NULL;
}
+ state->EndOfWAL = false;
state->errormsg_buf[0] = '\0';
/*
@@ -558,6 +561,7 @@ XLogDecodeNextRecord(XLogReaderState *state, bool nonblocking)
/* reset error state */
state->errormsg_buf[0] = '\0';
decoded = NULL;
+ state->EndOfWAL = false;
state->abortedRecPtr = InvalidXLogRecPtr;
state->missingContrecPtr = InvalidXLogRecPtr;
@@ -640,25 +644,21 @@ restart:
Assert(pageHeaderSize <= readOff);
/*
- * Read the record length.
+ * Validate the record header.
*
- * NB: Even though we use an XLogRecord pointer here, the whole record
- * header might not fit on this page. xl_tot_len is the first field of the
- * struct, so it must be on this page (the records are MAXALIGNed), but we
- * cannot access any other fields until we've verified that we got the
- * whole header.
- */
- record = (XLogRecord *) (state->readBuf + RecPtr % XLOG_BLCKSZ);
- total_len = record->xl_tot_len;
-
- /*
- * If the whole record header is on this page, validate it immediately.
- * Otherwise do just a basic sanity check on xl_tot_len, and validate the
- * rest of the header after reading it from the next page. The xl_tot_len
+ * Even though we use an XLogRecord pointer here, the whole record header
+ * might not fit on this page. If the whole record header is on this page,
+ * validate it immediately. Even otherwise xl_tot_len must be on this page
+ * (it is the first field of MAXALIGNed records), but we still cannot
+ * access any further fields until we've verified that we got the whole
+ * header, so do just a basic sanity check on record length, and validate
+ * the rest of the header after reading it from the next page. The length
* check is necessary here to ensure that we enter the "Need to reassemble
* record" code path below; otherwise we might fail to apply
* ValidXLogRecordHeader at all.
*/
+ record = (XLogRecord *) (state->readBuf + RecPtr % XLOG_BLCKSZ);
+
if (targetRecOff <= XLOG_BLCKSZ - SizeOfXLogRecord)
{
if (!ValidXLogRecordHeader(state, RecPtr, state->DecodeRecPtr, record,
@@ -668,18 +668,14 @@ restart:
}
else
{
- /* XXX: more validation should be done here */
- if (total_len < SizeOfXLogRecord)
- {
- report_invalid_record(state,
- "invalid record length at %X/%X: wanted %u, got %u",
- LSN_FORMAT_ARGS(RecPtr),
- (uint32) SizeOfXLogRecord, total_len);
+ if (!ValidXLogRecordLength(state, RecPtr, record))
goto err;
- }
+
gotheader = false;
}
+ total_len = record->xl_tot_len;
+
/*
* Find space to decode this record. Don't allow oversized allocation if
* the caller requested nonblocking. Otherwise, we *have* to try to
@@ -1106,16 +1102,47 @@ XLogReaderInvalReadState(XLogReaderState *state)
}
/*
- * Validate an XLOG record header.
+ * Validate record length of an XLOG record header.
*
- * This is just a convenience subroutine to avoid duplicated code in
- * XLogReadRecord. It's not intended for use from anywhere else.
+ * This is substantially a part of ValidXLogRecordHeader. But XLogReadRecord
+ * needs this separate from the function in case of a partial record header.
*/
static bool
-ValidXLogRecordHeader(XLogReaderState *state, XLogRecPtr RecPtr,
- XLogRecPtr PrevRecPtr, XLogRecord *record,
- bool randAccess)
+ValidXLogRecordLength(XLogReaderState *state, XLogRecPtr RecPtr,
+ XLogRecord *record)
{
+ if (record->xl_tot_len == 0)
+ {
+ char *p;
+ char *pe;
+
+ /*
+ * We are almost sure reaching the end of WAL, make sure that the
+ * whole page after the record is filled with zeroes.
+ */
+ p = (char *) record;
+ pe = p + XLOG_BLCKSZ - (RecPtr & (XLOG_BLCKSZ - 1));
+
+ while (*p == 0 && p < pe)
+ p++;
+
+ if (p == pe)
+ {
+ /*
+ * The page after the record is completely zeroed. That suggests
+ * we don't have a record after this point. We don't bother
+ * checking the pages after since they are not zeroed in the case
+ * of recycled segments.
+ */
+ report_invalid_record(state, "empty record at %X/%X",
+ LSN_FORMAT_ARGS(RecPtr));
+
+ /* notify end-of-wal to callers */
+ state->EndOfWAL = true;
+ return false;
+ }
+ }
+
if (record->xl_tot_len < SizeOfXLogRecord)
{
report_invalid_record(state,
@@ -1124,6 +1151,24 @@ ValidXLogRecordHeader(XLogReaderState *state, XLogRecPtr RecPtr,
(uint32) SizeOfXLogRecord, record->xl_tot_len);
return false;
}
+
+ return true;
+}
+
+/*
+ * Validate an XLOG record header.
+ *
+ * This is just a convenience subroutine to avoid duplicated code in
+ * XLogReadRecord. It's not intended for use from anywhere else.
+ */
+static bool
+ValidXLogRecordHeader(XLogReaderState *state, XLogRecPtr RecPtr,
+ XLogRecPtr PrevRecPtr, XLogRecord *record,
+ bool randAccess)
+{
+ if (!ValidXLogRecordLength(state, RecPtr, record))
+ return false;
+
if (!RmgrIdIsValid(record->xl_rmid))
{
report_invalid_record(state,
@@ -1222,6 +1267,31 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
XLogSegNoOffsetToRecPtr(segno, offset, state->segcxt.ws_segsize, recaddr);
+ StaticAssertStmt(XLOG_PAGE_MAGIC != 0, "XLOG_PAGE_MAGIC is zero");
+
+ if (hdr->xlp_magic == 0)
+ {
+ /* Regard an empty page as End-Of-WAL */
+ int i;
+
+ for (i = 0; i < XLOG_BLCKSZ && phdr[i] == 0; i++);
+ if (i == XLOG_BLCKSZ)
+ {
+ char fname[MAXFNAMELEN];
+
+ XLogFileName(fname, state->seg.ws_tli, segno,
+ state->segcxt.ws_segsize);
+
+ report_invalid_record(state,
+ "empty page in log segment %s, offset %u",
+ fname,
+ offset);
+ state->EndOfWAL = true;
+ return false;
+ }
+
+ /* The same condition will be caught as invalid magic number */
+ }
if (hdr->xlp_magic != XLOG_PAGE_MAGIC)
{
char fname[MAXFNAMELEN];
@@ -1307,6 +1377,14 @@ XLogReaderValidatePageHeader(XLogReaderState *state, XLogRecPtr recptr,
LSN_FORMAT_ARGS(hdr->xlp_pageaddr),
fname,
offset);
+
+ /*
+ * If the page address is less than expected we assume it is an unused
+ * page in a recycled segment.
+ */
+ if (hdr->xlp_pageaddr < recaddr)
+ state->EndOfWAL = true;
+
return false;
}
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index b41e6826643..caa3b5e5b31 100644
--- a/src/backend/access/transam/xlogrecovery.c
+++ b/src/backend/access/transam/xlogrecovery.c
@@ -1626,7 +1626,7 @@ PerformWalRecovery(void)
/* just have to read next record after CheckPoint */
Assert(xlogreader->ReadRecPtr == CheckPointLoc);
replayTLI = CheckPointTLI;
- record = ReadRecord(xlogprefetcher, LOG, false, replayTLI);
+ record = ReadRecord(xlogprefetcher, WARNING, false, replayTLI);
}
if (record != NULL)
@@ -1735,7 +1735,7 @@ PerformWalRecovery(void)
}
/* Else, try to fetch the next WAL record */
- record = ReadRecord(xlogprefetcher, LOG, false, replayTLI);
+ record = ReadRecord(xlogprefetcher, WARNING, false, replayTLI);
} while (record != NULL);
/*
@@ -1789,11 +1789,19 @@ PerformWalRecovery(void)
InRedo = false;
}
- else
+ else if (xlogreader->EndOfWAL)
{
/* there are no WAL records following the checkpoint */
ereport(LOG,
- (errmsg("redo is not required")));
+ errmsg("redo is not required"));
+
+ }
+ else
+ {
+ /* broken record found */
+ ereport(WARNING,
+ errmsg("redo is skipped"),
+ errhint("This suggests WAL file corruption. You might need to check the database."));
}
/*
@@ -3024,6 +3032,7 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
for (;;)
{
char *errormsg;
+ XLogRecPtr ErrRecPtr = InvalidXLogRecPtr;
record = XLogPrefetcherReadRecord(xlogprefetcher, &errormsg);
if (record == NULL)
@@ -3045,6 +3054,18 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
{
abortedRecPtr = xlogreader->abortedRecPtr;
missingContrecPtr = xlogreader->missingContrecPtr;
+ ErrRecPtr = abortedRecPtr;
+ }
+ else
+ {
+ /*
+ * EndRecPtr is the LSN we tried to read but failed. In the
+ * case of decoding error, it is at the end of the failed
+ * record but we don't have a means for now to know EndRecPtr
+ * is pointing to which of the beginning or ending of the
+ * failed record.
+ */
+ ErrRecPtr = xlogreader->EndRecPtr;
}
if (readFile >= 0)
@@ -3055,13 +3076,15 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
/*
* We only end up here without a message when XLogPageRead()
- * failed - in that case we already logged something. In
- * StandbyMode that only happens if we have been triggered, so we
- * shouldn't loop anymore in that case.
+ * failed- in that case we already logged something. In StandbyMode
+ * that only happens if we have been triggered, so we shouldn't
+ * loop anymore in that case. When EndOfWAL is true, we don't emit
+ * the message immediately and instead will show it as a part of a
+ * decent end-of-wal message later.
*/
- if (errormsg)
- ereport(emode_for_corrupt_record(emode, xlogreader->EndRecPtr),
- (errmsg_internal("%s", errormsg) /* already translated */ ));
+ if (!xlogreader->EndOfWAL && errormsg)
+ ereport(emode_for_corrupt_record(emode, ErrRecPtr),
+ errmsg_internal("%s", errormsg) /* already translated */ );
}
/*
@@ -3091,11 +3114,14 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
/* Great, got a record */
return record;
}
- else
- {
- /* No valid record available from this source */
- lastSourceFailed = true;
+ Assert(ErrRecPtr != InvalidXLogRecPtr);
+
+ /* No valid record available from this source */
+ lastSourceFailed = true;
+
+ if (!fetching_ckpt)
+ {
/*
* If archive recovery was requested, but we were still doing
* crash recovery, switch to archive recovery and retry using the
@@ -3108,11 +3134,16 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
* we'd have no idea how far we'd have to replay to reach
* consistency. So err on the safe side and give up.
*/
- if (!InArchiveRecovery && ArchiveRecoveryRequested &&
- !fetching_ckpt)
+ if (!InArchiveRecovery && ArchiveRecoveryRequested)
{
+ /*
+ * We don't report this as LOG, since we don't stop recovery
+ * here
+ */
ereport(DEBUG1,
- (errmsg_internal("reached end of WAL in pg_wal, entering archive recovery")));
+ errmsg_internal("reached end of WAL at %X/%X on timeline %u in pg_wal during crash recovery, entering archive recovery",
+ LSN_FORMAT_ARGS(ErrRecPtr),
+ replayTLI));
InArchiveRecovery = true;
if (StandbyModeRequested)
StandbyMode = true;
@@ -3133,12 +3164,24 @@ ReadRecord(XLogPrefetcher *xlogprefetcher, int emode,
continue;
}
- /* In standby mode, loop back to retry. Otherwise, give up. */
- if (StandbyMode && !CheckForStandbyTrigger())
- continue;
- else
- return NULL;
+ /*
+ * recovery ended.
+ *
+ * Emit a decent message if we met end-of-WAL. Otherwise we should
+ * have already emitted an error message.
+ */
+ if (xlogreader->EndOfWAL)
+ ereport(LOG,
+ errmsg("reached end of WAL at %X/%X on timeline %u",
+ LSN_FORMAT_ARGS(ErrRecPtr), replayTLI),
+ (errormsg ? errdetail_internal("%s", errormsg) : 0));
}
+
+ /* In standby mode, loop back to retry. Otherwise, give up. */
+ if (StandbyMode && !CheckForStandbyTrigger())
+ continue;
+ else
+ return NULL;
}
}
@@ -3233,11 +3276,16 @@ retry:
case XLREAD_WOULDBLOCK:
return XLREAD_WOULDBLOCK;
case XLREAD_FAIL:
+ Assert(!StandbyMode || CheckForStandbyTrigger());
+
if (readFile >= 0)
close(readFile);
readFile = -1;
readLen = 0;
readSource = XLOG_FROM_ANY;
+
+ /* promotion exit is not end-of-WAL */
+ xlogreader->EndOfWAL = !StandbyMode;
return XLREAD_FAIL;
case XLREAD_SUCCESS:
break;
@@ -3898,7 +3946,8 @@ emode_for_corrupt_record(int emode, XLogRecPtr RecPtr)
{
static XLogRecPtr lastComplaint = 0;
- if (readSource == XLOG_FROM_PG_WAL && emode == LOG)
+ /* use currentSource as readSource is reset at failure */
+ if (currentSource == XLOG_FROM_PG_WAL && emode <= WARNING)
{
if (RecPtr == lastComplaint)
emode = DEBUG1;
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index f6ef0ace2c4..c6d7be66885 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -472,10 +472,9 @@ WalReceiverMain(void)
else if (len < 0)
{
ereport(LOG,
- (errmsg("replication terminated by primary server"),
- errdetail("End of WAL reached on timeline %u at %X/%X.",
- startpointTLI,
- LSN_FORMAT_ARGS(LogstreamResult.Write))));
+ errmsg("replication terminated by primary server at %X/%X on timeline %u.",
+ LSN_FORMAT_ARGS(LogstreamResult.Write),
+ startpointTLI));
endofwal = true;
break;
}
diff --git a/src/bin/pg_waldump/pg_waldump.c b/src/bin/pg_waldump/pg_waldump.c
index 9993378ca58..26a4125b301 100644
--- a/src/bin/pg_waldump/pg_waldump.c
+++ b/src/bin/pg_waldump/pg_waldump.c
@@ -1168,9 +1168,16 @@ main(int argc, char **argv)
exit(0);
if (errormsg)
- pg_fatal("error in WAL record at %X/%X: %s",
- LSN_FORMAT_ARGS(xlogreader_state->ReadRecPtr),
- errormsg);
+ {
+ if (xlogreader_state->EndOfWAL)
+ pg_log_info("end of WAL at %X/%X: %s",
+ LSN_FORMAT_ARGS(xlogreader_state->EndRecPtr),
+ errormsg);
+ else
+ pg_fatal("error in WAL record at %X/%X: %s",
+ LSN_FORMAT_ARGS(xlogreader_state->EndRecPtr),
+ errormsg);
+ }
XLogReaderFree(xlogreader_state);
diff --git a/src/include/access/xlogreader.h b/src/include/access/xlogreader.h
index 6afec33d418..264afb6a78e 100644
--- a/src/include/access/xlogreader.h
+++ b/src/include/access/xlogreader.h
@@ -205,6 +205,7 @@ struct XLogReaderState
*/
XLogRecPtr ReadRecPtr; /* start of last record read */
XLogRecPtr EndRecPtr; /* end+1 of last record read */
+ bool EndOfWAL; /* was the last attempt EOW? */
/*
* Set at the end of recovery: the start point of a partial record at the
diff --git a/src/test/recovery/t/011_crash_recovery.pl b/src/test/recovery/t/011_crash_recovery.pl
index 1b57d01046d..bde16b7cfa7 100644
--- a/src/test/recovery/t/011_crash_recovery.pl
+++ b/src/test/recovery/t/011_crash_recovery.pl
@@ -9,7 +9,9 @@ use warnings;
use PostgreSQL::Test::Cluster;
use PostgreSQL::Test::Utils;
use Test::More;
+use IPC::Run;
+my $reached_eow_pat = "reached end of WAL at ";
my $node = PostgreSQL::Test::Cluster->new('primary');
$node->init(allows_streaming => 1);
$node->start;
@@ -47,7 +49,15 @@ is($node->safe_psql('postgres', qq[SELECT pg_xact_status('$xid');]),
# Crash and restart the postmaster
$node->stop('immediate');
+my $logstart = get_log_size($node);
$node->start;
+my $max_attempts = 360;
+while ($max_attempts-- >= 0)
+{
+ last if (find_in_log($node, $reached_eow_pat, $logstart));
+ sleep 0.5;
+}
+ok ($max_attempts >= 0, "end-of-wal is logged");
# Make sure we really got a new xid
cmp_ok($node->safe_psql('postgres', 'SELECT pg_current_xact_id()'),
@@ -60,4 +70,100 @@ is($node->safe_psql('postgres', qq[SELECT pg_xact_status('$xid');]),
$stdin .= "\\q\n";
$tx->finish; # wait for psql to quit gracefully
+my $segsize = $node->safe_psql('postgres',
+ qq[SELECT setting FROM pg_settings WHERE name = 'wal_segment_size';]);
+
+# make sure no records afterwards go to the next segment
+$node->safe_psql('postgres', qq[
+ SELECT pg_switch_wal();
+ CHECKPOINT;
+ CREATE TABLE t();
+]);
+$node->stop('immediate');
+
+# identify REDO WAL file
+my $cmd = "pg_controldata -D " . $node->data_dir();
+$cmd = ['pg_controldata', '-D', $node->data_dir()];
+$stdout = '';
+$stderr = '';
+IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr;
+ok($stdout =~ /^Latest checkpoint's REDO WAL file:[ \t] *(.+)$/m,
+ "checkpoint file is identified");
+my $chkptfile = $1;
+
+# identify the last record
+my $walfile = $node->data_dir() . "/pg_wal/$chkptfile";
+$cmd = ['pg_waldump', $walfile];
+$stdout = '';
+$stderr = '';
+my $lastrec;
+IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr;
+foreach my $l (split(/\r?\n/, $stdout))
+{
+ $lastrec = $l;
+}
+ok(defined $lastrec, "last WAL record is extracted");
+ok($stderr =~ /end of WAL at ([0-9A-F\/]+): .* at \g1/,
+ "pg_waldump emits the correct ending message");
+
+# read the last record LSN excluding leading zeroes
+ok ($lastrec =~ /, lsn: 0\/0*([1-9A-F][0-9A-F]+),/,
+ "LSN of the last record identified");
+my $lastlsn = $1;
+
+# corrupt the last record
+my $offset = hex($lastlsn) % $segsize;
+open(my $segf, '+<', $walfile) or die "failed to open $walfile\n";
+seek($segf, $offset, 0); # halfway corrupt the last record
+print $segf "\0\0\0\0";
+close($segf);
+
+# pg_waldump complains about the corrupted record
+$stdout = '';
+$stderr = '';
+IPC::Run::run $cmd, '>', \$stdout, '2>', \$stderr;
+ok($stderr =~ /error: error in WAL record at 0\/$lastlsn: .* at 0\/$lastlsn/,
+ "pg_waldump emits the correct error message");
+
+# also server complains
+$logstart = get_log_size($node);
+$node->start;
+$max_attempts = 360;
+while ($max_attempts-- >= 0)
+{
+ last if (find_in_log($node, "WARNING: invalid record length at 0/$lastlsn: wanted [0-9]+, got 0",
+ $logstart));
+ sleep 0.5;
+}
+ok($max_attempts >= 0, "header error is logged at $lastlsn");
+
+# no end-of-wal message should be seen this time
+ok(!find_in_log($node, $reached_eow_pat, $logstart),
+ "false log message is not emitted");
+
+$node->stop('immediate');
+
done_testing();
+
+#### helper routines
+# return the size of logfile of $node in bytes
+sub get_log_size
+{
+ my ($node) = @_;
+
+ return (stat $node->logfile)[7];
+}
+
+# find $pat in logfile of $node after $off-th byte
+sub find_in_log
+{
+ my ($node, $pat, $off) = @_;
+
+ $off = 0 unless defined $off;
+ my $log = PostgreSQL::Test::Utils::slurp_file($node->logfile);
+ return 0 if (length($log) <= $off);
+
+ $log = substr($log, $off);
+
+ return $log =~ m/$pat/;
+}
--
2.25.1
--sMP3l7aO1Ldl3x+Z--
^ permalink raw reply [nested|flat] 29+ messages in thread
* can we mark upper/lower/textlike functions leakproof?
@ 2024-07-30 21:35 Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Dunstan @ 2024-07-30 21:35 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Several years ago, an EDB customer complained that if they used a
functional index involving upper(), lower(), or textlike(), where RLS
was involved, the indexes were not used because these functions are not
marked leakproof. We presented the customer with several options for
addressing the problem, the simplest of which was simply to mark the
functions as leakproof, and this was the solution they adopted.
The consensus of discussion at the time among our senior developers was
that there was probably no reason why at least upper() and lower()
should not be marked leakproof, and quite possibly initcap() and
textlike() also. It was suggested that we had not been terribly rigorous
in assessing whether or not functions can be considered leakproof.
At the time we should have asked the community about it, but we didn't.
Fast forward to now. The customer has found no observable ill effects of
marking these functions leakproof. The would like to know if there is
any reason why we can't mark them leakproof, so that they don't have to
do this in every database of every cluster they use.
Thoughts?
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
@ 2024-07-30 22:51 ` David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: David Rowley @ 2024-07-30 22:51 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan <[email protected]> wrote:
> Fast forward to now. The customer has found no observable ill effects of
> marking these functions leakproof. The would like to know if there is
> any reason why we can't mark them leakproof, so that they don't have to
> do this in every database of every cluster they use.
>
> Thoughts?
According to [1], it's just not been done yet due to concerns about
risk to reward ratios. Nobody mentioned any reason why it couldn't
be, but there were some fears that future code changes could yield new
failure paths.
David
[1] https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
@ 2024-07-31 09:47 ` Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Andrew Dunstan @ 2024-07-31 09:47 UTC (permalink / raw)
To: David Rowley <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
> On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<[email protected]> wrote:
>> Fast forward to now. The customer has found no observable ill effects of
>> marking these functions leakproof. The would like to know if there is
>> any reason why we can't mark them leakproof, so that they don't have to
>> do this in every database of every cluster they use.
>>
>> Thoughts?
> According to [1], it's just not been done yet due to concerns about
> risk to reward ratios. Nobody mentioned any reason why it couldn't
> be, but there were some fears that future code changes could yield new
> failure paths.
>
> David
>
> [1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
Hmm, somehow I missed that thread in searching, and clearly I'd
forgotten it.
Still, I'm not terribly convinced by arguments along the lines you're
suggesting. "Sufficient unto the day is the evil thereof." Maybe we need
a test to make sure we don't make changes along those lines, although I
have no idea what such a test would look like.
cheers
andrew
--
Andrew Dunstan
EDB:https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
@ 2024-07-31 13:14 ` Joe Conway <[email protected]>
2024-07-31 13:38 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
0 siblings, 2 replies; 29+ messages in thread
From: Joe Conway @ 2024-07-31 13:14 UTC (permalink / raw)
To: Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On 7/31/24 05:47, Andrew Dunstan wrote:
> On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
>> On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<[email protected]> wrote:
>>> Fast forward to now. The customer has found no observable ill effects of
>>> marking these functions leakproof. The would like to know if there is
>>> any reason why we can't mark them leakproof, so that they don't have to
>>> do this in every database of every cluster they use.
>>>
>>> Thoughts?
>> According to [1], it's just not been done yet due to concerns about
>> risk to reward ratios. Nobody mentioned any reason why it couldn't
>> be, but there were some fears that future code changes could yield new
>> failure paths.
>>
>> David
>>
>> [1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
>
> Hmm, somehow I missed that thread in searching, and clearly I'd
> forgotten it.
>
> Still, I'm not terribly convinced by arguments along the lines you're
> suggesting. "Sufficient unto the day is the evil thereof." Maybe we need
> a test to make sure we don't make changes along those lines, although I
> have no idea what such a test would look like.
I think I have expressed this opinion before (which was shot down), and
I will grant that it is hand-wavy, but I will give it another try.
In my opinion, for this use case and others, it should be possible to
redact the values substituted into log messages based on some criteria.
One of those criteria could be "I am in a leakproof call right now". In
fact in a similar fashion, an extension ought to be able to mutate the
log message based on the entire string, e.g. when "ALTER
ROLE...PASSWORD..." is spotted I would like to be able to redact
everything after "PASSWORD".
Yes it might render the error message unhelpful, but I know of users
that would accept that tradeoff in order to get better performance and
security on their production workloads. Or in some cases (e.g. PASSWORD)
just better security.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-07-31 13:38 ` Andrew Dunstan <[email protected]>
1 sibling, 0 replies; 29+ messages in thread
From: Andrew Dunstan @ 2024-07-31 13:38 UTC (permalink / raw)
To: Joe Conway <[email protected]>; David Rowley <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
On 2024-07-31 We 9:14 AM, Joe Conway wrote:
> On 7/31/24 05:47, Andrew Dunstan wrote:
>> On 2024-07-30 Tu 6:51 PM, David Rowley wrote:
>>> On Wed, 31 Jul 2024 at 09:35, Andrew Dunstan<[email protected]>
>>> wrote:
>>>> Fast forward to now. The customer has found no observable ill
>>>> effects of
>>>> marking these functions leakproof. The would like to know if there is
>>>> any reason why we can't mark them leakproof, so that they don't
>>>> have to
>>>> do this in every database of every cluster they use.
>>>>
>>>> Thoughts?
>>> According to [1], it's just not been done yet due to concerns about
>>> risk to reward ratios. Nobody mentioned any reason why it couldn't
>>> be, but there were some fears that future code changes could yield new
>>> failure paths.
>>>
>>> David
>>>
>>> [1]https://postgr.es/m/02BDFCCF-BDBB-4658-9717-4D95F9A91561%40thebuild.com
>>>
>>
>> Hmm, somehow I missed that thread in searching, and clearly I'd
>> forgotten it.
>>
>> Still, I'm not terribly convinced by arguments along the lines you're
>> suggesting. "Sufficient unto the day is the evil thereof." Maybe we
>> need a test to make sure we don't make changes along those lines,
>> although I have no idea what such a test would look like.
>
>
> I think I have expressed this opinion before (which was shot down),
> and I will grant that it is hand-wavy, but I will give it another try.
>
> In my opinion, for this use case and others, it should be possible to
> redact the values substituted into log messages based on some
> criteria. One of those criteria could be "I am in a leakproof call
> right now". In fact in a similar fashion, an extension ought to be
> able to mutate the log message based on the entire string, e.g. when
> "ALTER ROLE...PASSWORD..." is spotted I would like to be able to
> redact everything after "PASSWORD".
>
> Yes it might render the error message unhelpful, but I know of users
> that would accept that tradeoff in order to get better performance and
> security on their production workloads. Or in some cases (e.g.
> PASSWORD) just better security.
>
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-07-31 17:39 ` Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
1 sibling, 1 reply; 29+ messages in thread
From: Robert Haas @ 2024-07-31 17:39 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 31, 2024 at 9:14 AM Joe Conway <[email protected]> wrote:
> In my opinion, for this use case and others, it should be possible to
> redact the values substituted into log messages based on some criteria.
> One of those criteria could be "I am in a leakproof call right now". In
> fact in a similar fashion, an extension ought to be able to mutate the
> log message based on the entire string, e.g. when "ALTER
> ROLE...PASSWORD..." is spotted I would like to be able to redact
> everything after "PASSWORD".
This might be helpful, and unfortunately I'm all too familiar with the
ALTER ROLE...PASSWORD example, but I think it's not really related to
the question of whether we can mark upper() and lower() leakproof.
If there are some inputs that cause upper() and lower() to fail and
others that do not, the functions aren't leakproof, because an
attacker can extract information about values that they can't see by
feeding those values into these functions and seeing whether they get
a failure or not. It doesn't matter what error message is produced;
the fact that the function throws an error of any kind for some input
values but enough for others is enough to make it unsafe, and it seems
to me that we've repeatedly found that there's often a way to turn
even what seems like a small leak into a very large one, so we need to
be quite careful here.
Annoyingly, we have a WHOLE BUNCH of different code paths that need to
be assessed individually here. I think we can ignore the fact that
upper() can throw errors when it's unclear which collation to use; I
think that's a property of the query string rather than the input
value. It's a bit less clear whether we can ignore out of memory
conditions, but my judgement is that a possible OOM from a small
allocation is not generally going to be useful as an attack vector. If
a long string produces an error and a short one doesn't, that might
qualify as a real leak. And other errors that depend on the input
value are also leaks. So let's go through the code paths:
- When lc_ctype_is_c(), we call asc_toupper(), which calls
pg_ascii_toupper(), which just replaces a-z with A-Z. No errors.
- When mylocale->provider == COLLPROVIDER_ICU, we call icu_to_uchar()
and icu_convert_case(). icu_to_uchar() calls uchar_length(), which has
this:
if (U_FAILURE(status) && status != U_BUFFER_OVERFLOW_ERROR)
ereport(ERROR,
(errmsg("%s failed: %s",
"ucnv_toUChars", u_errorName(status))));
I don't know what errors can be reported here, or if this ever fails
in practice, so I can't prove it never fails consistently for some
particular input string. uchar_convert() and icu_convert_case() have
similar error reporting.
- When mylocale->provider == COLLPROVIDER_BUILTIN, we call
unicode_strupper() which calls unicode_to_utf8() which clearly throws
no errors. Likewise unicode_utf8len() does not error. I don't see how
we can get an error out of this path.
- In cases not covered by the above, we take different paths depending
on whether a multi-byte encoding is in use. In single-byte encodings,
we rely on either pg_toupper() or toupper_l(). The latter is an
OS-provided function so can't ereport(), and the former calls either
does the work itself or calls toupper() which again is an OS-provided
function and can't report().
- Finally, when mylocale == NULL or the provider is COLLPROVIDER_LIBC
and the encoding is multi-byte, we use char2wchar(), then towupper_l()
or towupper(), then wchar2char(). The whole thing can fall apart if
the string is too long, which might be enough to declare this
leakproof but it depends on whether the error guarded by /* Overflow
paranoia */ is really just paranoia or whether it's actually
reachable. Otherwise, towupper*() won't ereport because it's not part
of PG, so we need to assess char2wchar() and wchar2char(). Here I note
that char2wchar() claims that it does an ereport() if the input is
invalidly encoded. This is kind of surprising when you think about it,
because our usual policy is not to allow invalidly encoded data into
the database in the first place, but whoever wrote this thought it
would be possible to hit this case "if LC_CTYPE locale is different
from the database encoding." But it seems that the logic here dates to
commit 2ab0796d7a3a7116a79b65531fd33f1548514b52 back in 2011, so it
seems at least possible to me that we've tightened things up enough
since then that you can't actually hit this any more. But then again,
maybe not.
So in summary, I think upper() is ... pretty close to leakproof. But
if ICU sometimes fails on certain strings, then it isn't. And if the
multi-byte libc path can be made to fail reliably either with really
long strings or with certain choices of the LC_CTYPE locale, then it
isn't.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-07-31 18:03 ` Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
0 siblings, 2 replies; 29+ messages in thread
From: Tom Lane @ 2024-07-31 18:03 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
Robert Haas <[email protected]> writes:
> If there are some inputs that cause upper() and lower() to fail and
> others that do not, the functions aren't leakproof, because an
> attacker can extract information about values that they can't see by
> feeding those values into these functions and seeing whether they get
> a failure or not.
> [ rather exhaustive analysis redacted ]
> So in summary, I think upper() is ... pretty close to leakproof. But
> if ICU sometimes fails on certain strings, then it isn't. And if the
> multi-byte libc path can be made to fail reliably either with really
> long strings or with certain choices of the LC_CTYPE locale, then it
> isn't.
The problem here is that marking these functions leakproof is a
promise about a *whole bunch* of code, much of it not under our
control; worse, there's no reason to think all that code is stable.
A large fraction of it didn't even exist a few versions ago.
Even if we could convince ourselves that the possible issues Robert
mentions aren't real at the moment, I think marking these leakproof
is mighty risky. It's unlikely we'd remember to revisit the marking
the next time someone drops a bunch of new code in here.
regards, tom lane
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
@ 2024-07-31 18:43 ` Joe Conway <[email protected]>
2024-07-31 19:54 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 11:17 ` Re: can we mark upper/lower/textlike functions leakproof? Laurenz Albe <[email protected]>
1 sibling, 3 replies; 29+ messages in thread
From: Joe Conway @ 2024-07-31 18:43 UTC (permalink / raw)
To: Tom Lane <[email protected]>; Robert Haas <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 7/31/24 14:03, Tom Lane wrote:
> Robert Haas <[email protected]> writes:
>> If there are some inputs that cause upper() and lower() to fail and
>> others that do not, the functions aren't leakproof, because an
>> attacker can extract information about values that they can't see by
>> feeding those values into these functions and seeing whether they get
>> a failure or not.
>
>> [ rather exhaustive analysis redacted ]
>
>> So in summary, I think upper() is ... pretty close to leakproof. But
>> if ICU sometimes fails on certain strings, then it isn't. And if the
>> multi-byte libc path can be made to fail reliably either with really
>> long strings or with certain choices of the LC_CTYPE locale, then it
>> isn't.
>
> The problem here is that marking these functions leakproof is a
> promise about a *whole bunch* of code, much of it not under our
> control; worse, there's no reason to think all that code is stable.
> A large fraction of it didn't even exist a few versions ago.
>
> Even if we could convince ourselves that the possible issues Robert
> mentions aren't real at the moment, I think marking these leakproof
> is mighty risky. It's unlikely we'd remember to revisit the marking
> the next time someone drops a bunch of new code in here.
I still maintain that there is a whole host of users that would accept
the risk of side channel attacks via existence of an error or not, if
they could only be sure nothing sensitive leaks directly into the logs
or to the clients. We should give them that choice.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-07-31 19:54 ` Andrew Dunstan <[email protected]>
2 siblings, 0 replies; 29+ messages in thread
From: Andrew Dunstan @ 2024-07-31 19:54 UTC (permalink / raw)
To: Joe Conway <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; +Cc: David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 2024-07-31 We 2:43 PM, Joe Conway wrote:
> On 7/31/24 14:03, Tom Lane wrote:
>> Robert Haas <[email protected]> writes:
>>> If there are some inputs that cause upper() and lower() to fail and
>>> others that do not, the functions aren't leakproof, because an
>>> attacker can extract information about values that they can't see by
>>> feeding those values into these functions and seeing whether they get
>>> a failure or not.
>>
>>> [ rather exhaustive analysis redacted ]
First, thanks you very much, Robert for the analysis.
>>
>>> So in summary, I think upper() is ... pretty close to leakproof. But
>>> if ICU sometimes fails on certain strings, then it isn't. And if the
>>> multi-byte libc path can be made to fail reliably either with really
>>> long strings or with certain choices of the LC_CTYPE locale, then it
>>> isn't.
>>
>> The problem here is that marking these functions leakproof is a
>> promise about a *whole bunch* of code, much of it not under our
>> control; worse, there's no reason to think all that code is stable.
>> A large fraction of it didn't even exist a few versions ago.
>>
>> Even if we could convince ourselves that the possible issues Robert
>> mentions aren't real at the moment, I think marking these leakproof
>> is mighty risky. It's unlikely we'd remember to revisit the marking
>> the next time someone drops a bunch of new code in here.
>
>
> I still maintain that there is a whole host of users that would accept
> the risk of side channel attacks via existence of an error or not, if
> they could only be sure nothing sensitive leaks directly into the logs
> or to the clients. We should give them that choice.
>
As I meant to say in my previous empty reply, I think your suggestions
make lots of sense.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-07-31 20:10 ` Robert Haas <[email protected]>
2024-07-31 20:42 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2 siblings, 1 reply; 29+ messages in thread
From: Robert Haas @ 2024-07-31 20:10 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 31, 2024 at 2:43 PM Joe Conway <[email protected]> wrote:
> I still maintain that there is a whole host of users that would accept
> the risk of side channel attacks via existence of an error or not, if
> they could only be sure nothing sensitive leaks directly into the logs
> or to the clients. We should give them that choice.
I'm not sure what design you have in mind. A lot of possible designs
seem to end up like this:
1. You can't directly select the invisible value.
2. But you can write a plpgsql procedure that tries a bunch of things
in a loop and catches errors and uses which things error and which
things don't to figure out and return the invisible value.
And I would argue that's not really that useful. Especially if that
plpgsql procedure can extract the hidden values in like 1ms/row.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-07-31 20:42 ` Joe Conway <[email protected]>
2024-08-01 11:57 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Joe Conway @ 2024-07-31 20:42 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 7/31/24 16:10, Robert Haas wrote:
> On Wed, Jul 31, 2024 at 2:43 PM Joe Conway <[email protected]> wrote:
>> I still maintain that there is a whole host of users that would accept
>> the risk of side channel attacks via existence of an error or not, if
>> they could only be sure nothing sensitive leaks directly into the logs
>> or to the clients. We should give them that choice.
>
> I'm not sure what design you have in mind. A lot of possible designs
> seem to end up like this:
>
> 1. You can't directly select the invisible value.
>
> 2. But you can write a plpgsql procedure that tries a bunch of things
> in a loop and catches errors and uses which things error and which
> things don't to figure out and return the invisible value.
>
> And I would argue that's not really that useful. Especially if that
> plpgsql procedure can extract the hidden values in like 1ms/row.
You are assuming that everyone allows direct logins with the ability to
create procedures. Plenty don't.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 20:42 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-01 11:57 ` Robert Haas <[email protected]>
2024-08-01 14:05 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Robert Haas @ 2024-08-01 11:57 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 31, 2024 at 4:42 PM Joe Conway <[email protected]> wrote:
> You are assuming that everyone allows direct logins with the ability to
> create procedures. Plenty don't.
Well, if you can send queries, then you can do the same thing, driven
by client-side logic.
If you can't directly send queries in any form, then I guess things
are different. But I don't really understand what kind of system you
have in mind.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 20:42 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:57 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-08-01 14:05 ` Joe Conway <[email protected]>
2024-08-01 14:43 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Joe Conway @ 2024-08-01 14:05 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 8/1/24 07:57, Robert Haas wrote:
> On Wed, Jul 31, 2024 at 4:42 PM Joe Conway <[email protected]> wrote:
>> You are assuming that everyone allows direct logins with the ability to
>> create procedures. Plenty don't.
>
> Well, if you can send queries, then you can do the same thing, driven
> by client-side logic.
Sure. Of course you should be monitoring your production servers for
anomalous workloads, no? "Gee, why is Joe running the same query
millions of times that keeps throwing errors? Maybe we should go see
what Joe is up to"
> If you can't directly send queries in any form, then I guess things
> are different.
Right, and there are plenty of those. I have even worked with at least
one rather large one on behalf of your employer some years ago.
> But I don't really understand what kind of system you have in mind.
Well I did say I was being hand wavy ;-)
It has been a long time since I thought deeply about this. I will try to
come back with something more concrete if no one beats me to it.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 20:42 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:57 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 14:05 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-01 14:43 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 29+ messages in thread
From: Robert Haas @ 2024-08-01 14:43 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Aug 1, 2024 at 10:05 AM Joe Conway <[email protected]> wrote:
> Sure. Of course you should be monitoring your production servers for
> anomalous workloads, no? "Gee, why is Joe running the same query
> millions of times that keeps throwing errors? Maybe we should go see
> what Joe is up to"
I think it's possible that something like this could be part of some
useful approach, but I think it's difficult. If it would take Joe a
month of pounding on the server to steal enough data to matter, then I
think monitoring could be one required part of an information
protection strategy. However, if Joe, or someone with Joe's
credentials, can steal all the secret data in under an hour, the
monitoring system probably doesn't help much. A human being probably
won't react quickly enough to stop something bad from happening,
especially if the person with Joe's credentials begins the attack at
2am on Christmas.
More generally, I think it's difficult for us to build infrastructure
into PostgreSQL that relies on complex assumptions about what the
customer environment is. To some extent, we are already relying on
users to prevent certain types of attacks. For example, RLS supposes
that timing attacks or plan-shape based attacks won't be feasible, but
we don't do anything to prevent them; we just hope the user takes care
of it. That's already a shaky assumption, because timing attacks could
well be feasible across a fairly deep application stack e.g. the user
issues an HTTP query for a web page and can detect variations in the
underlying database query latency.
When you start proposing assumptions that the user can't execute DDL
or can't execute SQL queries or that there's monitoring of the error
log in place, I feel the whole thing gets very hard to reason about.
First, you have to decide on exactly what the assumptions are - no
DDL, no direct SQL at all, something else? Different situations could
exist for different users, so whatever assumption we make will not
apply to everyone. Second, for some of this stuff, there's a sliding
scale. If we stipulate that a user is going to need a monitoring
system, how good does that monitoring system have to be? What does it
have to catch, and how quickly are the humans required to respond? If
we stipulate that the attacker can't execute SQL directly, how much
control over the generated SQL are they allowed to have?
I don't want to make it sound like I think it's hopeless to come up
with something clever here. The current situation kind of sucks, and I
do have hopes that there are better ideas out there. At the same time,
we need to be able to articulate clearly what we are and are not
guaranteeing and under what set of assumptions, and it doesn't seem
easy to me to come up with something satisfying.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-01 11:17 ` Laurenz Albe <[email protected]>
2024-08-01 13:54 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2 siblings, 1 reply; 29+ messages in thread
From: Laurenz Albe @ 2024-08-01 11:17 UTC (permalink / raw)
To: Joe Conway <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, 2024-07-31 at 14:43 -0400, Joe Conway wrote:
> I still maintain that there is a whole host of users that would accept
> the risk of side channel attacks via existence of an error or not, if
> they could only be sure nothing sensitive leaks directly into the logs
> or to the clients. We should give them that choice.
I think that you are right.
But what do you tell the users who would not accept that risk?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:17 ` Re: can we mark upper/lower/textlike functions leakproof? Laurenz Albe <[email protected]>
@ 2024-08-01 13:54 ` Joe Conway <[email protected]>
2024-08-01 14:26 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Joe Conway @ 2024-08-01 13:54 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; Tom Lane <[email protected]>; Robert Haas <[email protected]>; +Cc: Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 8/1/24 07:17, Laurenz Albe wrote:
> On Wed, 2024-07-31 at 14:43 -0400, Joe Conway wrote:
>> I still maintain that there is a whole host of users that would accept
>> the risk of side channel attacks via existence of an error or not, if
>> they could only be sure nothing sensitive leaks directly into the logs
>> or to the clients. We should give them that choice.
>
> I think that you are right.
thanks
> But what do you tell the users who would not accept that risk?
Document that the option should not be used if that is the case
¯\_(ツ)_/¯
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:17 ` Re: can we mark upper/lower/textlike functions leakproof? Laurenz Albe <[email protected]>
2024-08-01 13:54 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-01 14:26 ` Tom Lane <[email protected]>
2024-08-01 20:51 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Tom Lane @ 2024-08-01 14:26 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Laurenz Albe <[email protected]>; Robert Haas <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
Joe Conway <[email protected]> writes:
> On 8/1/24 07:17, Laurenz Albe wrote:
>> But what do you tell the users who would not accept that risk?
> Document that the option should not be used if that is the case
Are you proposing that we invent two levels of leakproofness
with different guarantees? That seems like a mess, not least
because there are going to be varying opinions about where we
should set the bar for the lower level.
regards, tom lane
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:17 ` Re: can we mark upper/lower/textlike functions leakproof? Laurenz Albe <[email protected]>
2024-08-01 13:54 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 14:26 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
@ 2024-08-01 20:51 ` Jacob Champion <[email protected]>
0 siblings, 0 replies; 29+ messages in thread
From: Jacob Champion @ 2024-08-01 20:51 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Joe Conway <[email protected]>; Laurenz Albe <[email protected]>; Robert Haas <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Aug 1, 2024 at 7:26 AM Tom Lane <[email protected]> wrote:
> Are you proposing that we invent two levels of leakproofness
> with different guarantees? That seems like a mess, not least
> because there are going to be varying opinions about where we
> should set the bar for the lower level.
It kind of reminds me of the kernel's "paranoia level" tunables, which
seem to proliferate in weird ways [1] and not make for a particularly
great UX.
--Jacob
[1] https://askubuntu.com/questions/1400874/what-does-perf-paranoia-level-four-do
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
@ 2024-07-31 20:26 ` Robert Haas <[email protected]>
2024-07-31 21:28 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
1 sibling, 2 replies; 29+ messages in thread
From: Robert Haas @ 2024-07-31 20:26 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 31, 2024 at 2:03 PM Tom Lane <[email protected]> wrote:
> The problem here is that marking these functions leakproof is a
> promise about a *whole bunch* of code, much of it not under our
> control; worse, there's no reason to think all that code is stable.
> A large fraction of it didn't even exist a few versions ago.
I think it's a fair critique. It could be reasonable to say, well, a
particular user could reasonably judge that the risk of marking
upper() as leak-proof is acceptable, but it's a little too risky for
us to want to do it as a project. After all, they can know things like
"we don't even use ICU," which we as a project cannot know.
However, the risk is that an end-user is going to be much less able to
evaluate what is and isn't safe than we are. I think some people are
going to be like -- well the core project doesn't mark enough stuff
leakproof, so I'll just go add markings to a bunch of stuff myself.
And they probably won't stop at stuff like UPPER which is almost
leakproof. They might add it to stuff such as LIKE which results in
immediately giving away the farm. By not giving people any guidance,
we invite them to make up their own rules.
Perhaps it's still right to be conservative; after all, no matter what
an end-user does, it's not a CVE for us, and CVEs suck. On the other
hand, shipping a system that is not useful in practice until you
modify a bunch of stuff also sucks, especially when it's not at all
clear which things are safe to modify.
I'm not sure what the right thing to do here is, but I think that it's
wrong to imagine that being unwilling to endorse probably-leakproof
things as leakproof -- or unwilling to put in the work to MAKE them
leakproof if they currently aren't -- has no security costs.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-07-31 21:28 ` Tom Lane <[email protected]>
1 sibling, 0 replies; 29+ messages in thread
From: Tom Lane @ 2024-07-31 21:28 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
Robert Haas <[email protected]> writes:
> I'm not sure what the right thing to do here is, but I think that it's
> wrong to imagine that being unwilling to endorse probably-leakproof
> things as leakproof -- or unwilling to put in the work to MAKE them
> leakproof if they currently aren't -- has no security costs.
Well, we *have* been a little bit spongy about that --- notably,
that texteq and friends are marked leakproof. But IMV, marking
upper/lower as leakproof is substantially riskier and offers
substantially less benefit than those did.
In general, I'm worried about a slippery slope here. If we
start marking things as leakproof because we cannot prove
they leak, rather than because we can prove they don't,
we are eventually going to find ourselves in a very bad place.
regards, tom lane
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-08-01 20:45 ` Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
1 sibling, 1 reply; 29+ messages in thread
From: Jacob Champion @ 2024-08-01 20:45 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Jul 31, 2024 at 1:26 PM Robert Haas <[email protected]> wrote:
> However, the risk is that an end-user is going to be much less able to
> evaluate what is and isn't safe than we are. I think some people are
> going to be like -- well the core project doesn't mark enough stuff
> leakproof, so I'll just go add markings to a bunch of stuff myself.
> And they probably won't stop at stuff like UPPER which is almost
> leakproof. They might add it to stuff such as LIKE which results in
> immediately giving away the farm. By not giving people any guidance,
> we invite them to make up their own rules.
+1.
Would it provide enough value for effort to explicitly mark leaky
procedures as such? Maybe that could shrink the grey area enough to be
protective?
--Jacob
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
@ 2024-08-02 01:02 ` Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Robert Haas @ 2024-08-02 01:02 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; +Cc: Tom Lane <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
<[email protected]> wrote:
> Would it provide enough value for effort to explicitly mark leaky
> procedures as such? Maybe that could shrink the grey area enough to be
> protective?
You mean like proleakproof = true/false/maybe?
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
@ 2024-08-02 13:48 ` Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Jacob Champion @ 2024-08-02 13:48 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Thu, Aug 1, 2024 at 6:03 PM Robert Haas <[email protected]> wrote:
>
> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
> <[email protected]> wrote:
> > Would it provide enough value for effort to explicitly mark leaky
> > procedures as such? Maybe that could shrink the grey area enough to be
> > protective?
>
> You mean like proleakproof = true/false/maybe?
Yeah, exactly.
--Jacob
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
@ 2024-08-02 13:58 ` Joe Conway <[email protected]>
2024-08-02 14:14 ` Re: can we mark upper/lower/textlike functions leakproof? David G. Johnston <[email protected]>
2024-08-02 15:07 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
0 siblings, 2 replies; 29+ messages in thread
From: Joe Conway @ 2024-08-02 13:58 UTC (permalink / raw)
To: Jacob Champion <[email protected]>; Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 8/2/24 09:48, Jacob Champion wrote:
> On Thu, Aug 1, 2024 at 6:03 PM Robert Haas <[email protected]> wrote:
>>
>> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
>> <[email protected]> wrote:
>> > Would it provide enough value for effort to explicitly mark leaky
>> > procedures as such? Maybe that could shrink the grey area enough to be
>> > protective?
>>
>> You mean like proleakproof = true/false/maybe?
>
> Yeah, exactly.
<dons flameproof suit>
Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
current behavior, 'lax' allows the 'maybe's to get pushed down, and
'off' ignores the leakproof attribute entirely and pushes down anything
that merits being pushed?
</dons flameproof suit>
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-02 14:14 ` David G. Johnston <[email protected]>
1 sibling, 0 replies; 29+ messages in thread
From: David G. Johnston @ 2024-08-02 14:14 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Jacob Champion <[email protected]>; Robert Haas <[email protected]>; Tom Lane <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Fri, Aug 2, 2024 at 6:58 AM Joe Conway <[email protected]> wrote:
> On 8/2/24 09:48, Jacob Champion wrote:
> > On Thu, Aug 1, 2024 at 6:03 PM Robert Haas <[email protected]>
> wrote:
> >>
> >> On Thu, Aug 1, 2024 at 4:45 PM Jacob Champion
> >> <[email protected]> wrote:
> >> > Would it provide enough value for effort to explicitly mark leaky
> >> > procedures as such? Maybe that could shrink the grey area enough to be
> >> > protective?
> >>
> >> You mean like proleakproof = true/false/maybe?
> >
> > Yeah, exactly.
>
> <dons flameproof suit>
> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> 'off' ignores the leakproof attribute entirely and pushes down anything
> that merits being pushed?
> </dons flameproof suit>
>
>
Another approach would be to do something like:
select "upper"!(column)
to demark within the query usage itself that this function with a maybe
leakproof attribute gets interpreted as yes.
or even something like:
select "upper"[leakproof](column)
This is both more readable and provides a way, not that we seem to need it,
to place more than one label (or just alternative labels using the same
syntax construct, like with explain (...)) inside the "array".
Discoverability of when to add such a marker would be left up to the query
author, with the safe default mode being a not leakproof interpretation.
David J.
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-02 15:07 ` Tom Lane <[email protected]>
2024-08-02 16:13 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
1 sibling, 1 reply; 29+ messages in thread
From: Tom Lane @ 2024-08-02 15:07 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Jacob Champion <[email protected]>; Robert Haas <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
Joe Conway <[email protected]> writes:
> <dons flameproof suit>
> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> 'off' ignores the leakproof attribute entirely and pushes down anything
> that merits being pushed?
> </dons flameproof suit>
So in other words, we might as well just remove RLS.
regards, tom lane
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-02 15:07 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
@ 2024-08-02 16:13 ` Joe Conway <[email protected]>
2024-08-02 16:22 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
0 siblings, 1 reply; 29+ messages in thread
From: Joe Conway @ 2024-08-02 16:13 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Jacob Champion <[email protected]>; Robert Haas <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On 8/2/24 11:07, Tom Lane wrote:
> Joe Conway <[email protected]> writes:
>> <dons flameproof suit>
>> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
>> current behavior, 'lax' allows the 'maybe's to get pushed down, and
>> 'off' ignores the leakproof attribute entirely and pushes down anything
>> that merits being pushed?
>> </dons flameproof suit>
>
> So in other words, we might as well just remove RLS.
Perhaps deciding where to draw the line for 'maybe' is too hard, but I
don't understand how you can say that in a general sense.
'strict' mode would provide the same guarantees as today. And even 'off'
has utility for cases where (1) no logins are allowed except for the app
(which is quite common in production environments) and no database
errors are propagated to the end client (again pretty standard best
practice); or (2) non-production environments, e.g. for testing or
debugging; or (3) use cases that utilize RLS as a notationally
convenient filtering mechanism and are not bothered by some leakage in
the worst case.
--
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 29+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-02 15:07 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-08-02 16:13 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
@ 2024-08-02 16:22 ` Jacob Champion <[email protected]>
0 siblings, 0 replies; 29+ messages in thread
From: Jacob Champion @ 2024-08-02 16:22 UTC (permalink / raw)
To: Joe Conway <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Haas <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]>
On Fri, Aug 2, 2024 at 9:13 AM Joe Conway <[email protected]> wrote:
>
> On 8/2/24 11:07, Tom Lane wrote:
> > Joe Conway <[email protected]> writes:
> >> <dons flameproof suit>
> >> Hmmm, and then have "leakproof_mode" = strict/lax/off where 'strict' is
> >> current behavior, 'lax' allows the 'maybe's to get pushed down, and
> >> 'off' ignores the leakproof attribute entirely and pushes down anything
> >> that merits being pushed?
> >> </dons flameproof suit>
> >
> > So in other words, we might as well just remove RLS.
>
> Perhaps deciding where to draw the line for 'maybe' is too hard, but I
> don't understand how you can say that in a general sense.
I'm more sympathetic to the "maybe" case, but for the "off" proposal I
find myself agreeing with Tom. If you want "off", turn off RLS.
> And even 'off'
> has utility for cases where (1) no logins are allowed except for the app
> (which is quite common in production environments) and no database
> errors are propagated to the end client (again pretty standard best
> practice);
I'm extremely skeptical of this statement, but I've been out of the
full-stack world for a bit. How does a modern best-practice
application hide the fact that it ran into an error and couldn't
complete a query?
> or (2) non-production environments, e.g. for testing or
> debugging; or
Changing the execution behavior between dev and prod seems like an
anti-goal. When would turning this off help you debug something?
> (3) use cases that utilize RLS as a notationally
> convenient filtering mechanism and are not bothered by some leakage in
> the worst case.
Catering to this use case doesn't seem like it should be a priority.
If a security feature is useful for you in a non-security setting,
awesome, but we shouldn't poke holes in it for that situation, nor
should it be surprising if the security gets stronger and becomes
harder to use for non-security.
--Jacob
^ permalink raw reply [nested|flat] 29+ messages in thread
end of thread, other threads:[~2024-08-02 16:22 UTC | newest]
Thread overview: 29+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2022-07-07 02:51 [PATCH] Make End-Of-Recovery error less scary Kyotaro Horiguchi <[email protected]>
2024-07-30 21:35 can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-30 22:51 ` Re: can we mark upper/lower/textlike functions leakproof? David Rowley <[email protected]>
2024-07-31 09:47 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 13:14 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 13:38 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 17:39 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 18:03 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-07-31 18:43 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-07-31 19:54 ` Re: can we mark upper/lower/textlike functions leakproof? Andrew Dunstan <[email protected]>
2024-07-31 20:10 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 20:42 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 11:57 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 14:05 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 14:43 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-01 11:17 ` Re: can we mark upper/lower/textlike functions leakproof? Laurenz Albe <[email protected]>
2024-08-01 13:54 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-01 14:26 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-08-01 20:51 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-07-31 20:26 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-07-31 21:28 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-08-01 20:45 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 01:02 ` Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]>
2024-08-02 13:48 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
2024-08-02 13:58 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-02 14:14 ` Re: can we mark upper/lower/textlike functions leakproof? David G. Johnston <[email protected]>
2024-08-02 15:07 ` Re: can we mark upper/lower/textlike functions leakproof? Tom Lane <[email protected]>
2024-08-02 16:13 ` Re: can we mark upper/lower/textlike functions leakproof? Joe Conway <[email protected]>
2024-08-02 16:22 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox