Scott Ribe writes:
> So, one last follow-up, perhaps \du or \du+ should show when a role is mapped
> that way. If I'd seen a clue to this setting that had been made "before I got
> here" it would have been figured out sooner.
\drds does already show this; of course, you have to know to look at
So, one last follow-up, perhaps \du or \du+ should show when a role is mapped
that way. If I'd seen a clue to this setting that had been made "before I got
here" it would have been figured out sooner.
I realize ALTER ROLE... SET... can be used to set many more defaults, and there
could be some
> On Aug 7, 2020, at 1:32 PM, Tom Lane wrote:
>
> Yes, you are. It looks like what you actually issued is
>
> ALTER USER akanzler SET role confidential_read_only;
>
> but that would have the effect that subsequent session starts would
> automatically do "SET ROLE confidential_read_only".
AHA!
On 8/7/20 12:40 PM, Adrian Klaver wrote:
On 8/7/20 12:27 PM, Scott Ribe wrote:
On Aug 7, 2020, at 1:08 PM, Adrian Klaver
wrote:
"Using this command, it is possible to either add privileges or
restrict one's privileges. If the session user role has the INHERIT
attribute, then it automaticall
On 8/7/20 12:27 PM, Scott Ribe wrote:
On Aug 7, 2020, at 1:08 PM, Adrian Klaver wrote:
"Using this command, it is possible to either add privileges or restrict one's
privileges. If the session user role has the INHERIT attribute, then it
automatically has all the privileges of every role that
Scott Ribe writes:
> So it would only have removed privs if I had used set role in the session,
> which I am not.
Yes, you are. It looks like what you actually issued is
ALTER USER akanzler SET role confidential_read_only;
but that would have the effect that subsequent session starts would
au
> On Aug 7, 2020, at 1:08 PM, Adrian Klaver wrote:
>
> "Using this command, it is possible to either add privileges or restrict
> one's privileges. If the session user role has the INHERIT attribute, then it
> automatically has all the privileges of every role that it could SET ROLE to;
> in t
On 8/7/20 11:56 AM, Scott Ribe wrote:
On Aug 7, 2020, at 12:45 PM, Tom Lane wrote:
If I'm reading this correctly, you have set things up so that any
session logging in as akanzler will immediately do "SET ROLE
confidential_read_only", after which it's the privileges of that
role not akanzler th
> On Aug 7, 2020, at 12:45 PM, Tom Lane wrote:
>
> If I'm reading this correctly, you have set things up so that any
> session logging in as akanzler will immediately do "SET ROLE
> confidential_read_only", after which it's the privileges of that
> role not akanzler that determine what happens.
Scott Ribe writes:
> On Aug 7, 2020, at 12:27 PM, Adrian Klaver wrote:
>> So what privileges does role 'confidential_read_only' have?
> read on everything
... including usage on the schema in question?
If I'm reading this correctly, you have set things up so that any
session logging in as akan
On Aug 7, 2020, at 12:27 PM, Adrian Klaver wrote:
>
> So what privileges does role 'confidential_read_only' have?
read on everything
I tried creating a new user without it, just doing the same grants otherwise as
for akanzler, that worked. Then I added that user to confidential_read_only,
sti
On 8/7/20 11:25 AM, Scott Ribe wrote:
On Aug 7, 2020, at 12:17 PM, Adrian Klaver wrote:
Well if this for the same line as before it represents table privileges. The
problem is with schema access. Continuing grasping at straws:
select * from pg_roles where rolname = 'aakanzler';
rolname | r
> On Aug 7, 2020, at 12:17 PM, Adrian Klaver wrote:
>
> Well if this for the same line as before it represents table privileges. The
> problem is with schema access. Continuing grasping at straws:
>
> select * from pg_roles where rolname = 'aakanzler';
rolname | rolsuper | rolinherit | rolcre
On 8/7/20 10:39 AM, Scott Ribe wrote:
On Aug 7, 2020, at 11:31 AM, Scott Ribe wrote:
Wondering if there's a code path somewhere that lets the default take
precedence???
So, I changed the defaults, now I see akanzler=arwdDxt/srv_risk, problem
persists
Well if this for the same line as bef
> On Aug 7, 2020, at 11:31 AM, Scott Ribe wrote:
>
> Wondering if there's a code path somewhere that lets the default take
> precedence???
So, I changed the defaults, now I see akanzler=arwdDxt/srv_risk, problem
persists
>
> What happens if you do?:
>
> select has_schema_privilege('akanzler', 'zoewang', 'usage');
risk_oltp_prod=# select has_schema_privilege('akanzler', 'zoewang', 'usage');
has_schema_privilege
--
t
(1 row)
> In psql what does
>
> \ddp
>
> show?
risk_oltp_prod=# \ddp
On 8/7/20 9:23 AM, Scott Ribe wrote:
Further update:
create a new user, grant all on schema & the table, works
reboot of server did not change anything, so the problem is in persistent state
What happens if you do?:
select has_schema_privilege('akanzler', 'zoewang', 'usage');
In psql what
Further update:
create a new user, grant all on schema & the table, works
reboot of server did not change anything, so the problem is in persistent state
FYI, REVOKE ALL ON SCHEMA... followed by GRANT ALL ON SCHEMA... did not change
anything
> On Aug 6, 2020, at 12:53 PM, Stephen Frost wrote:
>
> Are you 110% sure that you're actually connecting to the same instance
> in both cases (I'd say database too, but hopefully psql isn't lying to
> you about that on your prompt, but maybe double-check anyway...).
yes--double checked
> Have
Greetings,
* Scott Ribe (scott_r...@elevated-dev.com) wrote:
> when user akanzler tries to run query "SELECT * FROM zoewang.sometable...",
> it triggers this error:
>
> 2020-08-06 17:27:27.664 UTC [15914]: [3]
> user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
> permis
> On Aug 6, 2020, at 12:38 PM, Tom Lane wrote:
>
> Hmph. Any chance of getting a stack trace from the point of the error?
possibly
> Also, which PG version is this?
12.3
It is probably relevant that we cleaned up roles & privs yesterday, lots of
REVOKE & GRANT, and some DROP ROLE. I started
On 8/6/20 11:39 AM, Scott Ribe wrote:
On Aug 6, 2020, at 12:36 PM, Adrian Klaver wrote:
No triggers or FOREIGN KEYS?
No. No keys or indexes either--that was the entire table def.
echo "Hmph"
--
Adrian Klaver
adrian.kla...@aklaver.com
> On Aug 6, 2020, at 12:36 PM, Adrian Klaver wrote:
>
> No triggers or FOREIGN KEYS?
No. No keys or indexes either--that was the entire table def.
Scott Ribe writes:
> On Aug 6, 2020, at 12:22 PM, Tom Lane wrote:
>> Gonna need more context. The session-level user seems to have the
>> right privileges, but maybe something is happening inside a
>> security-definer function that doesn't have privileges?
> The only security definer function i
On Aug 6, 2020, at 12:22 PM, Tom Lane wrote:
>
> Gonna need more context. The session-level user seems to have the
> right privileges, but maybe something is happening inside a
> security-definer function that doesn't have privileges?
The only security definer function in the db is a simple pg_
On 8/6/20 11:35 AM, Scott Ribe wrote:
On Aug 6, 2020, at 12:22 PM, Adrian Klaver wrote:
Schema for the table?
Nothing relevant:
Column| Type | Collation | Nullable | Default
-+---+---+--+-
curve_name | characte
> On Aug 6, 2020, at 12:22 PM, Adrian Klaver wrote:
>
> Schema for the table?
Nothing relevant:
Column| Type | Collation | Nullable | Default
-+---+---+--+-
curve_name | character varying(30) | |
On 8/6/20 11:11 AM, Scott Ribe wrote:
when user akanzler tries to run query "SELECT * FROM zoewang.sometable...", it
triggers this error:
2020-08-06 17:27:27.664 UTC [15914]: [3]
user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
permission denied for schema zoewang at
Scott Ribe writes:
> when user akanzler tries to run query "SELECT * FROM zoewang.sometable...",
> it triggers this error:
> 2020-08-06 17:27:27.664 UTC [15914]: [3]
> user=akanzler,db=risk_oltp_prod,app=[unknown],client=10.8.170.24: ERROR:
> permission denied for schema zoewang at character 1
30 matches
Mail list logo
