Re: [HACKERS] proposal: session server side variables - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] proposal: session server side variables
Date
Msg-id alpine.DEB.2.20.1701102034300.11499@lancre
Whole thread Raw
In response to Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
Hello Craig,

>> I have submitted a proof of this fact in the form of a counter example which
>> (1) (pseudo) implements the use-case by logging into an audit table the fact
>> a user accesses the secure level (2) shows that the status of a non
>> transactional session variable used for keeping this status is wrong for the
>> use case in some cases (it says that all is well while appending to the
>> audit table failed).
>
> You've been assuming everyone else cares about auditing such access
> into a table.

No, I have not.

For the PosgreSQL product, I'm really assuming that a security feature 
should work in all cases, not just some cases with implicit uncheckable 
restrictions, especially restrictions related to transactions which is all 
a database is about. I think that providing a misleading feature is a bad 
idea.

Note that my blessing is not required. If a committer wants to add this 
then they can do it.

> But you're fixated on the idea that without that use case satisfied the 
> rest is useless, and that's simply not the case. Transactional vars are 
> only needed if you make _write_ changes to the DB that must be committed 
> atomically with the var change. If you're only doing (maybe expensive) 
> lookups, it doesn't matter.

It does not matter if and only if the transaction does not fail, not 
because the variable is not transactional. Basically, if it is 
untransactional, then it works only if it behaves exactly like a 
transaction...


> Again ... I think you've assumed everyone else is talking about the
> same security-related case you are.

I'm looking forward to see any use case which requires untransactional 
variables with permissions and works correctly without adding un-database 
constraints such as "please do not use in transactions that change any 
data because then it may or may not work".


> It's kind of like someone coming to you and saying they want to add an
> engine to their glider, and you explaining that it's totally useless
> to add an engine unless it can also function as a submarine. Um,
> that's nice, but not what they asked for.

Hmmm... I think that it is really like adding an engine on a glider which 
does not work if the glider flies under a cloud. You just have to recall 
that you should not fly under a cloud when the engine is turned on.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] Replication/backup defaults
Next
From: David Rowley
Date:
Subject: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together