New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: limit virtual tables to current database #11694
sql: limit virtual tables to current database #11694
Conversation
Reviewed 1 of 1 files at r1. pkg/sql/information_schema.go, line 540 at r2 (raw file):
How do we want this to behave if a user has no current database set? Comments from Reviewable |
Review status: 0 of 4 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed. pkg/sql/information_schema.go, line 540 at r2 (raw file): Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
It seems reasonable to me that only system tables will be returned. I believe this is the current behavior. Comments from Reviewable |
ba22bfb
to
e7c420a
Compare
Review status: 0 of 4 files reviewed at latest revision, 1 unresolved discussion, all commit checks successful. pkg/sql/information_schema.go, line 540 at r2 (raw file): Previously, jordanlewis (Jordan Lewis) wrote…
Ok, do we assert this behavior in tests? Comments from Reviewable |
e7c420a
to
170178a
Compare
Review status: 0 of 4 files reviewed at latest revision, 1 unresolved discussion, some commit checks pending. pkg/sql/information_schema.go, line 540 at r2 (raw file): Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Good point, done. This testing actually uncovered some issues with the patch. I moved this check into Comments from Reviewable |
a4cf0f2
to
3250416
Compare
Rebased (and reworked) this on top of #10196. I decided the easiest way to unify these two patches was a combination of temporarily setting the current database in the |
3250416
to
b6f048a
Compare
I may be confused about what we're doing here, but it seems that the crux of the visibility criterion is whether the target database is the current database in the session. What prevents a user from using "SET DATABASE = 'XXX'" to a database where the user has no permission and then seeing all its schema? Is that compatible with what you're trying to achieve? Reviewed 3 of 6 files at r5. pkg/sql/information_schema.go, line 558 at r5 (raw file):
I'd see a switch here or a loop with a table rather than this disjunction which is bound to become larger and unwieldable. pkg/sql/information_schema.go, line 640 at r5 (raw file):
I'd capture this entire condition in a helper function pkg/sql/testdata/information_schema, line 641 at r5 (raw file):
I think #8497 has been solved. Comments from Reviewable |
LGTM otherwise btw. Review status: 3 of 7 files reviewed at latest revision, 4 unresolved discussions, all commit checks successful. Comments from Reviewable |
Previously, we couldn't switch users if there was no current database. This commit remedies the issue.
b6f048a
to
a63b8bf
Compare
There's nothing preventing a user from doing that right now, but it's still compatible with the goal of this patch, which is enabling sufficient compatibility with postgres behavior to allow OID casts to work consistently. In postgres, I don't think users can connect to arbitrary databases, FWIW. TFTR! Review status: 0 of 8 files reviewed at latest revision, 4 unresolved discussions. pkg/sql/information_schema.go, line 558 at r5 (raw file): Previously, knz (kena) wrote…
Done. pkg/sql/information_schema.go, line 640 at r5 (raw file): Previously, knz (kena) wrote…
Done. pkg/sql/testdata/information_schema, line 641 at r5 (raw file): Previously, knz (kena) wrote…
I fixed this in a different PR. I'll pick up in a rebase. Comments from Reviewable |
Review status: 0 of 8 files reviewed at latest revision, 4 unresolved discussions. pkg/sql/testdata/information_schema, line 641 at r5 (raw file): Previously, jordanlewis (Jordan Lewis) wrote…
Err, no I didn't. Fixed - thanks for catching this! Comments from Reviewable |
Reviewed 1 of 1 files at r7, 5 of 7 files at r8. pkg/sql/information_schema.go, line 558 at r5 (raw file): Previously, jordanlewis (Jordan Lewis) wrote…
What about: switch name {
case informationSchemaName:
case pgCatalogName:
case sqlbase.SystemDB.Name:
default:
return false
}
return true pkg/sql/logic_test.go, line 402 at r8 (raw file):
I don' think this change is useful/necessary. (If you really care about escaping special chars in the db name then you'd need sqlEscape or something. Comments from Reviewable |
In postgres, the contents of tables in the `pg_catalog` and `information_schema` databases are limited to entries relating to the current database and system databases. This commit limits our implementation of these tables in the same way, unless the current user is root.
a63b8bf
to
2ec61af
Compare
Review status: 6 of 8 files reviewed at latest revision, 3 unresolved discussions, some commit checks pending. pkg/sql/information_schema.go, line 558 at r5 (raw file): Previously, knz (kena) wrote…
Much better thanks! pkg/sql/logic_test.go, line 402 at r8 (raw file): Previously, knz (kena) wrote…
The reason this is necessary is that the database name can be empty in tests. If that's the case, this line will fail without the extra quoting. Comments from Reviewable |
oh okthx |
In postgres, the contents of tables in the
pg_catalog
andinformation_schema
databases are limited to entries relating to the current database and system databases. This commit limits our implementation of these tables in the same way, unless the current user is root.This change is