Subject: Re: Should rolpassword be toastable?

From: Tom Lane <[email-masked]>
Date: Sat, 23 Sep 2023 10:39:22 -0400

Alexander Lakhin <[email-masked]> writes:
> When playing with oversized tuples, I've found that it's possible to set
> such oversized password for a user, that could not be validated.
> For example:
> ...
> psql -U "test_user" -c "SELECT 1"
> psql: error: connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:  cannot read pg_class without having 
> selected a database

My inclination is to fix this by removing pg_authid's toast table.
I was not in favor of "let's attach a toast table to every catalog"
to begin with, and I think this failure graphically illustrates
why that was not as great an idea as some people thought.
I also don't think it's worth trying to make it really work.

I'm also now more than just slightly skeptical about whether
pg_database should have a toast table.  Has anybody tried,
say, storing a daticurules field wide enough to end up
out-of-line?

			regards, tom lane

---

From: Alexander Lakhin <[email-masked]>
Date: Sat, 23 Sep 2023 21:00:00 +0300

> say, storing a daticurules field wide enough to end up

I tried, but failed, because pg_database accessed in InitPostgres() before
assigning MyDatabaseId only via the function GetDatabaseTupleByOid(),
which doesn't unpack the database tuple.
Another access to a system catalog with unassigned MyDatabaseId might occur
in the has_privs_of_role() call, but pg_auth_members contains no toastable
attributes.
So for now only pg_authid is worthy of condemnation, AFAICS.

Best regards,
Alexander

---

From: Alexander Lakhin <[email-masked]>
Date: Thu, 19 Sep 2024 06:00:00 +0300

Hello Tom and Nathan,

> So for now only pg_authid is worthy of condemnation, AFAICS.

Let me remind you of this issue in light of b52c4fc3c.
Yes, it's opposite, but maybe it makes sense to fix it now in the hope that
~1 year of testing will bring something helpful for both changes.

Best regards,
Alexander

---

From: Nathan Bossart <[email-masked]>
Date: Thu, 19 Sep 2024 09:22:31 -0500

> ~1 year of testing will bring something helpful for both changes.

Hm.  It does seem like there's little point in giving pg_authid a TOAST
table, as rolpassword is the only varlena column, and it obviously has
problems.  But wouldn't removing it just trade one unhelpful internal error
when trying to log in for another when trying to add a really long password
hash (which hopefully nobody is really trying to do in practice)?  I wonder
if we could make this a little more user-friendly.

-- 
nathan

---

From: Tom Lane <[email-masked]>
Date: Thu, 19 Sep 2024 10:31:15 -0400

> if we could make this a little more user-friendly.

We could put an arbitrary limit (say, half of BLCKSZ) on the length of
passwords.

			regards, tom lane

---

From: Nathan Bossart <[email-masked]>
Date: Thu, 19 Sep 2024 12:44:32 -0500

> We could put an arbitrary limit (say, half of BLCKSZ) on the length of

Something like that could be good enough.  I was thinking about actually
validating that the hash had the correct form, but that might be a little
more complex than is warranted here.

-- 
nathan