Обсуждение: 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