On 2019-06-22 19:09:41 +0200, Karsten Hilbert wrote:
> On Sat, Jun 22, 2019 at 06:40:10PM +0200, Peter J. Holzer wrote:
> > > How is it useful in a normally configured database to return row data in
> > > error messages?
> >
> > This is extremely useful. It tells you what data didn't match your
> > program's expectations. Otherwise you just get a vague "unique
> > constraint violation"
>
> Sure, except some argue that PG not send such information to
> the *client* by *default*, which seems to have some merit
> (the default should, however, keep logging such data to the
> PG log)
Well, William didn't talk about a default. He asked "how is it useful in
a normally configured database", implying that this would never be
useful in production, only for development and debugging.
I strongly disagree with this. When my (non-developer) colleagues down
the hall import their data, I want them to get helpful error messages,
so that they can check their data and possibly fix it before bothering
me. There is no possible data leak - it is their data, they already know
it. But I don't necessarily want to give them access to the postgres
log: That might contain information that they are not supposed to see.
The database cannot know whether data is sensitive or not. The
application can, and it is up to the application to handle sensitive
data appropriately. The database already takes care of not divulging
data that the application couldn't access anyway. So removing this from
the error message doesn't reduce the data that could be reduced
potentially - but it shifts the burden either to the developer (who
would probably have a much harder time to recreate the information and
probably wont) or to operations, which has to think about giving access
to server log files, etc.
There may be situations where where removing this information from the
logs makes sense - I am not convinced that it even improves security in
the majority of cases.
hp
--
_ | Peter J. Holzer | we build much bigger, better disasters now
|_|_) | | because we have much more sophisticated
| | | hjp@hjp.at | management tools.
__/ | http://www.hjp.at/ | -- Ross Anderson <https://www.edge.org/>
