> On Apr 19, 2021, at 6:41 PM, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Apr 19, 2021 at 12:53:29PM -0400, Tom Lane wrote:
>> FWIW, I think that putting them both in contrib makes the most
>> sense from a structural standpoint.
>>
>> Either way, though, you'll still need the proposed option to
>> let the executable issue a CREATE EXTENSION to get the shlib
>> loaded. Unless somebody is proposing that the extension be
>> installed-by-default like plpgsql, and that I am unequivocally
>> not for.
>
> Agreed. Something like src/extensions/ would be a tempting option,
> but I don't think that it is a good idea to introduce a new piece of
> infrastructure at this stage, so moving both to contrib/ would be the
> best balance with the current pieces at hand.
There is another issue to consider. Installing pg_amcheck in no way opens up an avenue of attack that I can see. It
isjust a client application with no special privileges. But installing amcheck arguably opens a line of attack; not
oneas significant as installing pageinspect, but of the same sort. Amcheck allows privileged database users to
potentiallyget information from the tables that would otherwise be invisible even to them according to mvcc rules. (Is
thisalready the case via some other functionality? Maybe this security problem already exists?) If the privileged
databaseuser has file system access, then this is not at all concerning, since they can already just open the files in
atool of their choice, but I don't see any reason why installations should require that privileged database users also
beprivileged to access the file system.
If you are not buying my argument here, perhaps a reference to how encryption functions are evaluated might help you
seemy point of view. You don't ask, "can the attacker recover the plain text from the encrypted text", but rather,
"canthe attacker tell the difference between encrypted plain text and encrypted random noise." That's because it is
incrediblyhard to reason about what an attacker might be able to learn. Even though learning about old data using
amcheckwould be hard, you can't say that an attacker would never be able to recover information about deleted rows. As
such,security conscious installations are within reason to refuse to install it.
Since amcheck (and to a much larger extent, pageinspect) open potential data leakage issues, it makes sense for some
securityconscious sites to refuse to install it. pg_amcheck on the other hand could be installed everywhere. I
understandwhy it might *feel* like pg_amcheck and amcheck have to both be installed to work, but I don't think that
pointof view makes much sense in reality. The computer running the client and the computer running the server are
frequentlynot the same computer.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
