Re: proposal: session server side variables

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: proposal: session server side variables
Date: 2017-01-10 20:35:45
Message-ID: alpine.DEB.2.20.1701102034300.11499@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2017-01-10 21:14:23 CONNECTION LIMIT and Parallel Query don't play well together
Previous Message Stephen Frost 2017-01-10 20:06:59 Re: Replication/backup defaults