Re: [HACKERS] proposal: session server side variables

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] proposal: session server side variables
Дата
Msg-id alpine.DEB.2.20.1701102034300.11499@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] proposal: session server side variables  (Craig Ringer <craig@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: [HACKERS] Replication/backup defaults
Следующее
От: David Rowley
Дата:
Сообщение: [HACKERS] CONNECTION LIMIT and Parallel Query don't play well together