| From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> | 
|---|---|
| To: | ishii(at)sraoss(dot)co(dot)jp | 
| Cc: | hoshiai(at)sraoss(dot)co(dot)jp, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Proposal to suppress errors thrown by to_reg*() | 
| Date: | 2019-03-19 10:09:59 | 
| Message-ID: | 20190319.190959.25783254.horiguchi.kyotaro@lab.ntt.co.jp | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
At Tue, 19 Mar 2019 17:54:01 +0900 (JST), Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> wrote in <20190319(dot)175401(dot)646838939186238443(dot)t-ishii(at)sraoss(dot)co(dot)jp>
> > It seems to be a different thing. The oid 1647239 would be a
> > table in public schema or any schema that the user has access
> > to. If search_path contained only unprivileged schemas, the
> > function silently ignores such schemas.
> > 
> > => set search_path to s1;       -- the user doesn't have access to this schema.
> > => select to_regclass('t1')::oid; -- the table is really exists.
> >> to_regclass 
> >> -------------
> >>  
> >> (1 row)
> 
> I (and Hoshiai-san) concern about following case:
> 
> # revoke usage on schema s1 from foo;
> REVOKE
> :
> [connect as foo]
> test=> select to_regclass('s1.t1')::oid;
> ERROR:  permission denied for schema s1
That works in a transaction. It looks right that the actually
revoked schema cannot be accessed.
S1:foo: begin;
S2:su : revoke usage on schema s1 from foo;
S1:foo: select to_regclass('s1.t1')::oid;
>  to_regclass 
> -------------
>        16418
S2:foo: commit;
S2:foo: select to_regclass('s1.t1')::oid;
> ERROR:  permission denied for schema s1
regards.
-- 
Kyotaro Horiguchi
NTT Open Source Software Center
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro HORIGUCHI | 2019-03-19 10:14:49 | Re: [HACKERS] Block level parallel vacuum | 
| Previous Message | Masahiko Sawada | 2019-03-19 10:01:06 | Re: [HACKERS] Block level parallel vacuum |