Обсуждение: Question about psql meta-command with schema option doesn't use visibilityrule
Question about psql meta-command with schema option doesn't use visibilityrule
От
Tatsuro Yamada
Дата:
Hi, I have a question that is a specification of permission check (visibilityrule) for psql meta-command with schema option. According to the source code [1], there is no check if a schema option is added. As a result, a role that is not granted can see other roles' object names. We might say it's okay because it's a name, not contents (data), but It seems not preferable, I think. The following is a reproducer using \dX commands. Note: It is not only \dX but also \d because it uses the same permission check function (processSQLNamePattern). The reproduction procedure (including some results): ================================================ -- Create role a, b as non-superuser create role a nosuperuser; create role b nosuperuser; grant CREATE on database postgres to a; -- Create schema s_a, table hoge, and its extend stats by role a set role a; create schema s_a; create table s_a.hoge(a int, b int); create statistics s_a.hoge_ext on a,b from s_a.hoge; set search_path to public, s_a; -- Run \dX and \dX s_a.* by role a: OK (since schema s_a was created by role a) \dX List of extended statistics Schema | Name | Definition | Ndistinct | Dependencies | MCV --------+----------+----------------+-----------+--------------+--------- s_a | hoge_ext | a, b FROM hoge | defined | defined | defined (1 row) \dX s_a.* List of extended statistics Schema | Name | Definition | Ndistinct | Dependencies | MCV --------+----------+----------------+-----------+--------------+--------- s_a | hoge_ext | a, b FROM hoge | defined | defined | defined (1 row) -- Run \dX by role b: OK -- (not displayed is fine since role b can't see info of role a) reset role; set role b; \dX List of extended statistics Schema | Name | Definition | Ndistinct | Dependencies | MCV --------+------+------------+-----------+--------------+----- (0 rows) -- Run \dX with schema by role b: OK?? (It should be NG?) -- this case is a point in my question \dX s_a.* List of extended statistics Schema | Name | Definition | Ndistinct | Dependencies | MCV --------+----------+--------------------+-----------+--------------+--------- s_a | hoge_ext | a, b FROM s_a.hoge | defined | defined | defined (1 row) -- clean-up reset role; drop schema s_a cascade; revoke CREATE on DATABASE postgres FROM a; drop role a; drop role b; ================================================ From the above results, I expected "\dX s_a.*" doesn't show any info as same as "\dX". but info is displayed. I'm wondering this behavior. I'm maybe missing something, but if this is a problem, I'll send a patch. Any comments are welcome! [1]: processSQLNamePattern in src/fe_utils/string_utils.c if (schemabuf.len > 2) { /* We have a schema pattern, so constrain the schemavar */ /* Optimize away a "*" pattern */ if (strcmp(schemabuf.data, "^(.*)$") != 0 && schemavar) { WHEREAND(); appendPQExpBuffer(buf, "%s OPERATOR(pg_catalog.~) ", schemavar); appendStringLiteralConn(buf, schemabuf.data, conn); if (PQserverVersion(conn) >= 120000) appendPQExpBufferStr(buf, " COLLATE pg_catalog.default"); appendPQExpBufferChar(buf, '\n'); } } else { /* No schema pattern given, so select only visible objects */ if (visibilityrule) { WHEREAND(); appendPQExpBuffer(buf, "%s\n", visibilityrule); } } Thanks, Tatsuro Yamada
Re: Question about psql meta-command with schema option doesn't use visibilityrule
От
"David G. Johnston"
Дата:
On Sunday, November 7, 2021, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> wrote:
According to the source code [1], there is no check if a schema
option is added. As a result, a role that is not granted can see
other roles' object names.
We might say it's okay because it's a name, not contents (data),
but It seems not preferable, I think.
No, we are not interested in changing this long-standing documented behavior. The contents of the catalogs are visible to all. So even if this was something to consider, psql is not the correct scope.
David J.
Re: Question about psql meta-command with schema option doesn't use visibilityrule
От
"David G. Johnston"
Дата:
On Sunday, November 7, 2021, Tatsuro Yamada <tatsuro.yamada.tf@nttcom.co.jp> wrote:
I have a question that is a specification of permission check
(visibilityrule) for psql meta-command with schema option.
From the above results, I expected "\dX s_a.*" doesn't show any info
as same as "\dX". but info is displayed. I'm wondering this behavior.
I'm maybe missing something, but if this is a problem, I'll send a
patch. Any comments are welcome!
Visibility means search_path, not permission. If s_a is not in the search_paths it objects are not visible unqualified but can be seen (catalog) when schema qualified.
David J.
Re: Question about psql meta-command with schema option doesn't use visibilityrule
От
Tatsuro Yamada
Дата:
Hi David, > I have a question that is a specification of permission check > (visibilityrule) for psql meta-command with schema option. > > Visibility means search_path, not permission. If s_a is not in the search_paths it objects are not visible unqualifiedbut can be seen (catalog) when schema qualified. Thanks for your comments! I understood them: - all users can show System catalog (pg_catalog. *) is a specification, so it is not a bug - visibility and permission are not the same (I confused it before, oops) Regards, Tatsuro Yamada