Thread: Should rolpassword be toastable?
Hello hackers, 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: SELECT format('CREATE ROLE test_user LOGIN PASSWORD ''SCRAM-SHA-256$' || repeat('0', 2000000) || '4096:NuDacwYSUxeOeFUEf3ivTQ==$Wgvq3OCYrJI6eUfvKlAzn4p/j3mzgWzXbVnWeFK1qhY=:r1qSP0j2QojCjLpFUjI0i6ckInvxJDKoyWnN3zF8WCM='';') \gexec -- the password is "pass" (One can achieve the same result with a large salt size, for example, 2048.) 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 I've tried to set attstorage = 'p' for the rolpassword attribute forcefully by dirty hacking genbki.pl, and as a result I get an error on CREATE ROLE: ERROR: row is too big: size 2000256, maximum size 8160 Best regards, Alexander
Alexander Lakhin <exclusion@gmail.com> 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
23.09.2023 17:39, Tom Lane wrote: > 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? 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