opt: check privileges after data sources in memo staleness check

[DrewKimball]

Previously, the opt.Metadata staleness check would check the access privileges for a data source immediately after checking that the data source still resolves as it originally did. This meant that the privilege check for one data source could occur before checking staleness of other data sources. Before #96045 this wasn't a problem, since these checks would happen in the order in which the data sources were resolved. But after #96045, the data sources were stored in a map instead of a slice, which made the order in which the checks are performed nondeterministic.

This change in behavior can cause queries to return insufficient privilege errors even when the current user has access privileges on all data sources referenced by the query. This is because the query may implicitly reference a table by ID if there is a foreign key relation from an explicitly referenced data source. If the database is changed, this ID reference will still resolve the same, but if the user is changed to one without privileges on that table, the staleness check will result in an error. This wasn't a problem before because the referencing table would always be checked first, causing the staleness check to finish without an error.

This patch fixes the bug by moving the privilege checks until after all data source resolution checks have succeeded.

Fixes #102375

Release note (bug fix): Fixed a bug introduced in versions 22.1.19, 22.2.8, and pre-release versions of 23.1 that could cause queries to return spurious insufficient privilege errors. For the bug to occur, two databases would need to have duplicate tables each with a foreign key reference to another table. The error would then occur if the same SQL string was executed against both databases concurrently by users that have privileges over only one of the tables.

[cockroach-teamcity]

This change is 

[DrewKimball]

I couldn't figure out how to make a logic test reproduce this error even with --stress and --race, but I've verified using the manual reproduction from #96045 #102375 that the problem is fixed.

[rytaft]

I think you have the wrong issue number, since #96045 is the PR you merged earlier.

[rytaft]

Maybe you meant #102375?

[rytaft]

Here's a logictest you can use that reproduces the issue for me:

statement ok
CREATE DATABASE testdb1;
USE testdb1;
CREATE TABLE ab (a INT PRIMARY KEY, b INT);
INSERT INTO ab VALUES (1, 1);
CREATE TABLE xy (x INT, y INT, FOREIGN KEY (x) REFERENCES ab(a));
GRANT ALL ON xy TO testuser;
GRANT ALL ON ab TO testuser;
ALTER ROLE testuser WITH LOGIN;

statement ok
CREATE DATABASE testdb2;
USE testdb2;
CREATE TABLE ab (a INT PRIMARY KEY, b INT);
INSERT INTO ab VALUES (1, 1);
CREATE TABLE xy (x INT, y INT, FOREIGN KEY (x) REFERENCES ab(a));
CREATE USER testuser2;
GRANT ALL ON xy TO testuser2;
GRANT ALL ON ab TO testuser2;
ALTER ROLE testuser2 WITH LOGIN;

user testuser

statement ok
USE testdb1

statement ok
INSERT into xy VALUES(1, 1)

user testuser2

statement ok
USE testdb2

statement ok
INSERT into xy VALUES(1, 1)

statement ok
INSERT into xy VALUES(1, 1)

user testuser

statement ok
USE testdb1

statement ok
INSERT into xy VALUES(1, 1)

[DrewKimball]

Maybe you meant #102375?

Yes, thanks for catching that.

[DrewKimball]

Here's a logictest you can use that reproduces the issue for me:

Huh, tried a similar one and didn't get anything, nice find!

[rytaft]

thanks for the quick fix!

Reviewed 2 of 2 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @cucaroach)

[rytaft]

pkg/sql/logictest/testdata/logic_test/schema line 1321 at r2 (raw file):

REVOKE ALL ON testdb2.xy FROM testuser2;
REVOKE ALL ON testdb2.ab FROM testuser2;
DROP USER testuser;

nit: testuser seems to exist by default so not sure you need to drop it

[DrewKimball]

Reviewable status: complete! 1 of 0 LGTMs obtained (waiting on @cucaroach and @rytaft)

---

pkg/sql/logictest/testdata/logic_test/schema line 1321 at r2 (raw file):

Previously, rytaft (Rebecca Taft) wrote…

nit: testuser seems to exist by default so not sure you need to drop it

Good point, Done.

[rytaft]

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (and 1 stale) (waiting on @cucaroach)

[DrewKimball]

TFTR!

bors r+

[craig]

Build succeeded:

• Bazel Essential CI (Cockroach)

[blathers-crl]

Encountered an error creating backports. Some common things that can go wrong:

1. The backport branch might have already existed.
2. There was a merge conflict.
3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.

---

error creating merge commit from 9381f84 to blathers/backport-release-22.1-102405: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 22.1.x failed. See errors above.

---

error creating merge commit from 9381f84 to blathers/backport-release-22.2-102405: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 22.2.x failed. See errors above.

---

error creating merge commit from 9381f84 to blathers/backport-release-23.1.0-102405: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 23.1.0 failed. See errors above.

---

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}