public inbox for pgsql-performance@postgresql.org
help / color / mirror / Atom feedFrom: Fabien COELHO <coelho@cri.ensmp.fr>
To: Pavel Luzanov <p.luzanov@postgrespro.ru>
Cc: PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: [HACKERS] proposal: schema variables
Date: Wed, 29 Aug 2018 20:10:02 +0200 (CEST)
Message-ID: <alpine.DEB.2.21.1808291954300.14012@lancre> (raw)
In-Reply-To: <66454695-1317-feb8-766a-a8daa75fde06@postgrespro.ru>
References: <CAFj8pRDY+m9OOxfO10R7J0PAkCCauM-TweaTrdsrsLGMb1VbEQ@mail.gmail.com>
<28924bcc-9242-9798-e4e8-9d83cea3fef6@dalibo.com>
<CAFj8pRBRxJ09ibuZT+KK3E+vc3-sXAz7HrbW3oVie7FwQRU-uQ@mail.gmail.com>
<ae98027e-25a7-b229-ffec-b05d68162718@dalibo.com>
<CAFj8pRATM44F1ugXxTn6aofxOa=3DZbqOJ17=EVyG+CEzsRQvw@mail.gmail.com>
<CAFj8pRDnoA3J2RM=WZJdYBXEiJUOfDv-gyJmp81Pq93jmrBb5g@mail.gmail.com>
<CAFj8pRCTz_CRez3vFo_Ta_m=KtOxBGHE9+T1QG3UgRbuURfzjA@mail.gmail.com>
<CAFj8pRA_jZYuTRHEMsv8CnZLBqmnS5xRjcZh-uf0nBWA7WrzMA@mail.gmail.com>
<alpine.DEB.2.21.1808211938510.11873@lancre>
<CAFj8pRCRUpNjX9Fb49SaADbRnCE69ndkOvtoeKxwvxetfJ8=kA@mail.gmail.com>
<alpine.DEB.2.21.1808220831550.10677@lancre>
<CAFj8pRCyvx37Fnw6yHdscGbbGo_Ak3WdeKiZ6arFW8JTA099YA@mail.gmail.com>
<alpine.DEB.2.21.1808230927090.31897@lancre>
<CAFj8pRAcFv09qOcbr09c2AbwZ9DGw5Hs6rPcYoo7r9OLdWWB2A@mail.gmail.com>
<alpine.DEB.2.21.1808231123050.31897@lancre>
<66454695-1317-feb8-766a-a8daa75fde06@postgrespro.ru>
Hello Pavel L.
>> I do not understand your point, as usual. I raise a factual issue about
>> security, and you do not answer how this can be solved with your proposal,
>> but appeal to argument of authority and declare your "strong opinion".
>>
>> I do not see any intrinsic opposition between having session objects and
>> transactions. Nothing prevents a session object to be transactional beyond
>> your willingness that it should not be.
>>
>> Now, I do expect all PostgreSQL features to be security-wise, whatever
>> their scope.
>>
>> I do not think that security should be traded for "cheap & fast", esp as
>> the sole use case for a feature is a security pattern that cannot be
>> implemented securely with it. This appears to me as a huge contradiction,
>> hence my opposition against this feature as proposed.
>
> I can't to agree with your position.
>
> Consider this example. I want to record some inappropriate user actions
> to audit table and rollback transaction. But aborting transaction will
> also abort record to audit table. So, do not use tables, becouse they
> have security implications.
Indeed, you cannot record a transaction failure from a transaction.
> This is very similar to your approach.
I understand that your point is that some use case could require a non
transactional session variable. I'm not sure of how the use case would go
on though, because once the "attacker" disconnects, the session variable
disappears, so it does not record that there was a problem.
Anyway, I'm not against having session variables per se. I'm argumenting
that there is a good case to have them transactional by default, and
possibly an option to have them non transactional if this is really needed
by some use case to provide.
The only use case put forward by Pavel S. is the security audit one
where a session variable stores that audit checks have been performed,
which AFAICS cannot be implemented securely with the proposed non
transactional session variables.
--
Fabien.
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: coelho@cri.ensmp.fr, p.luzanov@postgrespro.ru, pgsql-hackers@lists.postgresql.org
Subject: Re: [HACKERS] proposal: schema variables
In-Reply-To: <alpine.DEB.2.21.1808291954300.14012@lancre>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox