Re: How to revoke privileged from PostgreSQL's superuser

Oh this is an easy one. There are simpler solutions for PITR. Also, a PITR
is a very specific case of a database use, if it even uses one. Generally
speaking, you would not want to keep encrypted data within a database.
There simply isn't a need for it. Just use a file or a folder. You can't do
anything that you would normally do with a database if you can't read or
access any of your objects. It would just be a table of binary objects
without names, possibly access or creation dates depending on the level of
paranoia. Literally, you would have an int column and a binary object
column. What can you honestly do with that? You can't even link it to other
objects. It has no relational structure, hense the question. If there isn't
a relationship to anything then a relational database wouldn't really help
anything.

Also, I would probably keep the encryption key within the database anyway.
Otherwise, your objects could get permanently lost making the whole thing
moot in the first place.

Look, you either trust your DBAs or you don't. If you don't trust them, why
are they your DBA? This is like writing unit tests for unit tests or having
even higher levels of privilege than a superuser. It's turtles all the way
down.

~Ben

On Fri, Aug 10, 2018 at 4:12 PM, Rui DeSousa <rui(at)crazybean(dot)net> wrote:

>
>
> On Aug 6, 2018, at 10:45 AM, Bear Giles <bgiles(at)coyotesong(dot)com> wrote:
>
> then it's reasonable to ask if storing the information in a relational
> database is the best approach.
>
>
> Why? Just because its encrypted doesn’t mean it shouldn’t be stored in the
> database. What about PITR, how would that be handled? You basically would
> have to reimplement things the RDBMS system gives you for free by storing
> it outside the database. Don’t forget it's called a management system for
> a reason.
>