Re: pie-in-sky idea: 'sensitive' function parameters - Mailing list pgsql-hackers

From Chapman Flack
Subject Re: pie-in-sky idea: 'sensitive' function parameters
Date
Msg-id 5ED13A78.3050008@anastigmatix.net
Whole thread Raw
In response to Re: pie-in-sky idea: 'sensitive' function parameters  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: pie-in-sky idea: 'sensitive' function parameters
List pgsql-hackers
Just giving this thread a bump in honor of the mention of sensitive
things in logs in the cryptography unconference session.

I'm not partisan about any of the particular syntax examples I gave
earlier, but it seems like there were two key ingredients:

1.  In what is sent from the client to the server, certain parameters
    are marked as sensitive in ways that are obvious early at parse time,
    before having to look up or analyze anything.

2.  But those markings are later compared to the actual declarations of
    things, once those are resolved. It is an error either to send as
    'sensitive' a parameter that isn't so declared, or to forget to send
    as 'sensitive' one that is.

The first error is to prevent evildoers using the facility to hide values
from the logs arbitrarily in the queries they are sending.

The second error is to catch mistakes during app development. It's possible
that a query sent by an app under development won't have the right things
marked 'sensitive' yet, and it's possible those queries get exposed in the
logs because the early parse-time indication that they shouldn't be is
missing.

But at that stage of development, the values being sent shouldn't really
be sensitive ones, and making such a query an error ensures such omissions
are caught and fixed.

Regards,
-Chap



pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: possibility to read dumped table's name from file
Next
From: Robert Haas
Date:
Subject: Re: Expand the use of check_canonical_path() for more GUCs