Tightening the trust auth advice

[Magnus Hagander]

The page at https://www.postgresql.org/docs/current/auth-trust.html goes
through some length to explain why Trust is sometimes a good idea.

Is it really though? And in particular, aren't there better choices?

As a first step, I think we should put a  box on the page
explicitly saying that that trust, unless limited in pg_hba, will allow any
user to become superuser which allows them to bypass all other security
restrictions.

Second, we're kind of going out of our way to recommend setting unix socket
permissions etc -- in those cases, wouldn't it in almost every case just be
better for the user to use "peer" auth instead of trust, and we should
recommend them to use that instead? Is it really any less appropriate
and/or convenient? (It was listed as appropriate back in 2001
in 6f0f5bf2fbe, but the world has changed a bit in 20+ years..)

And finally, the sentence "It is seldom reasonable to use trust for any
TCP/IP connections other than those from localhost (127.0.0.1)." should
probably be amended with an ", and only reasonable for localhost if you
trust every single user on the host"?

Thoughts? I'll be happy to work up a patch if there's agreement on the
general idea.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/ 
 Work: https://www.redpill-linpro.com/ 

Re: The documentation for storage type 'plain' actually allows single byte header

[Laurenz Albe]

On Tue, 2023-01-10 at 15:53 +, PG Doc comments form wrote:
> https://www.postgresql.org/docs/devel/storage-toast.html - This is the
> development version.
> 
> > PLAIN prevents either compression or out-of-line storage; furthermore it
> > disables use of single-byte headers for varlena types. This is the only
> > possible strategy for columns of non-TOAST-able data types.
> 
> However, it does allow "single byte" headers. How to verify this?
> 
> CREATE EXTENSION pageinspect;
> CREATE TABLE test(a VARCHAR(1) STORAGE PLAIN);
> INSERT INTO test VALUES (repeat('A',10));
> 
> Now peek into the page with pageinspect functions
> 
> SELECT left(encode(t_data, 'hex'), 40) FROM
> heap_page_items(get_raw_page('test', 0));
> 
> This returned value of "1741414141414141414141".
> Here the first byte 0x17 = 0001 0111 in binary.
> Length + 1 is stored in the length bits (1-7). So Len = 0001011-1 = (11-1)
> [base-10] = 10 [base-10]
> which exactly matches the expected length. Further the data "41" repeated 10
> times also indicates character A (65 or 0x41 in ASCII) repeated 10 times.
> 
> SoThis does **not** disable 1-B header. That sentence should be removed
> from the documentation unless this is a bug.

I think that the documentation is wrong.  The attached patch removes the
offending half-sentence.

Yours,
Laurenz Albe
From 5bf0b43fe73384a21f59d9ad1f7a8d7cbc81f8c4 Mon Sep 17 00:00:00 2001
From: Laurenz Albe 
Date: Thu, 12 Jan 2023 15:41:56 +0100
Subject: [PATCH] Fix documentation for STORAGE PLAIN

Commit 3e23b68dac0, which introduced single-byte varlena headers,
added documentation that STORAGE PLAIN would prevent such single-byte
headers.  This has never been true.
---
 doc/src/sgml/storage.sgml | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/doc/src/sgml/storage.sgml b/doc/src/sgml/storage.sgml
index e5b9f3f1ff..4795a485d0 100644
--- a/doc/src/sgml/storage.sgml
+++ b/doc/src/sgml/storage.sgml
@@ -456,9 +456,7 @@ for storing TOAST-able columns on disk:
 
  
   PLAIN prevents either compression or
-  out-of-line storage; furthermore it disables use of single-byte headers
-  for varlena types.
-  This is the only possible strategy for
+  out-of-line storage.  This is the only possible strategy for
   columns of non-TOAST-able data types.
  
 
-- 
2.39.0

Background worker

[PG Doc comments form]

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/15/bgworker.html
Description:

Hi Team,

The glossary is a really nice summary of what each term means. The
background worker gives a nice summary as to what it does

"Background worker (process)
Process within an instance, which runs system- or user-supplied code. Serves
as infrastructure for several features in PostgreSQL, such as logical
replication and parallel queries. In addition, Extensions can add custom
background worker processes." 

Then it links to Chapter 48 For more information, see Chapter 48. to learn
more but I can't find any more information about logical replication and
parallel queries in relation with background workers aside from user
extensions. Would like to learn more about that thanks.

thanks and keep up the good work
Hussein

Re: Tightening the trust auth advice

[Jonathan S. Katz]

On 1/12/23 4:32 AM, Magnus Hagander wrote:
The page at https://www.postgresql.org/docs/current/auth-trust.html 
 goes through 
some length to explain why Trust is sometimes a good idea.


Is it really though? And in particular, aren't there better choices?


This first case it lists sounds like a good case for "peer" 
authentication...and the multi-user case it lists also sounds like a goo 
use for "peer".


The case that I think "trust" is good at, which we don't list, is doing 
local development / testing of PG.


As a first step, I think we should put a  box on the page 
explicitly saying that that trust, unless limited in pg_hba, will allow 
any user to become superuser which allows them to bypass all other 
security restrictions.


+1

Second, we're kind of going out of our way to recommend setting unix 
socket permissions etc -- in those cases, wouldn't it in almost every 
case just be better for the user to use "peer" auth instead of trust, 
and we should recommend them to use that instead? Is it really any less 
appropriate and/or convenient? (It was listed as appropriate back in 
2001 in 6f0f5bf2fbe, but the world has changed a bit in 20+ years..)


Yeah, I think forwarding folks to the documentation on "peer" is a good 
idea here. I don't know if we want to keep any language around for 
historical context "Prior to "peer" auth, "trust" was used for this but 
on modern systems you can use "peer" instead for better security."


And finally, the sentence "It is seldom reasonable to use trust for any 
TCP/IP connections other than those from localhost (127.0.0.1)." should 
probably be amended with an ", and only reasonable for localhost if you 
trust every single user on the host"?


I'd invert it: "It is not recommended to use "trust" for any TCP/IP 
(non-local) connection. You should use "trust" with localhost 
(127.0.0.1) connections only if you trust every single user on that host."


Thoughts? I'll be happy to work up a patch if there's agreement on the 
general idea.


Reading through this, I'm not shocked there's still a good amount of 
"trust" prevalent in the wild. I agree with tightening this up.


Jonathan



OpenPGP_signature
Description: OpenPGP digital signature