> On Apr 19, 2021, at 6:41 PM, Michael Paquier <mich...@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 is just a client application with no
special privileges. But installing amcheck arguably opens a line of attack;
not one as significant as installing pageinspect, but of the same sort.
Amcheck allows privileged database users to potentially get information from
the tables that would otherwise be invisible even to them according to mvcc
rules. (Is this already the case via some other functionality? Maybe this
security problem already exists?) If the privileged database user has file
system access, then this is not at all concerning, since they can already just
open the files in a tool of their choice, but I don't see any reason why
installations should require that privileged database users also be privileged
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 see my point of view. You don't ask,
"can the attacker recover the plain text from the encrypted text", but rather,
"can the attacker tell the difference between encrypted plain text and
encrypted random noise." That's because it is incredibly hard to reason about
what an attacker might be able to learn. Even though learning about old data
using amcheck would 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 security conscious sites to refuse to
install it. pg_amcheck on the other hand could be installed everywhere. I
understand why it might *feel* like pg_amcheck and amcheck have to both be
installed to work, but I don't think that point of view makes much sense in
reality. The computer running the client and the computer running the server
are frequently not the same computer.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
