On Dec24, 2010, at 04:16 , Tom Lane wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> On Dec23, 2010, at 16:54 , Tom Lane wrote:
>>> BTW, is it possible to set things up so that a REPLICATION account
>>> can be NOLOGIN, thereby making it really hard to abuse for other
>>> purposes? Or does the login privilege check come too soon?
>
>> Please don't. This violates the principle of least surprise big time!
>
> How so? (Please note I said *can be*, not *has to be*.)
Because a DBA might "ALTER ROLE replication WITH NOLOGIN", thinking he has
just disabled that role. Only to find out weeks later than he hasn't
and that someone has been using that role to stream weeks worth of
confidential data to who knows where.
The problem here is that you suggest NOLOGIN should mean "Not allowed
to issue SQL commands", which really isn't what the name "NOLOGIN"
conveys. The concept itself is perfectly fine, but the name is dangerously
confusing.
> The point of this is to ensure that if someone does illicitly come by
> the replication role's password, they can't use it to log in. They can
> still steal all your data, but they can't actually get into the
> database. I don't see why it's a bad idea to configure things that way.
It's perfectly fine to configure things that way, and is in fact what I would
do. I'd just prefer the name for that setting to convey it's actual meaning
which is why I suggested adding a SQL/NOSQL flag. (Or SESSION/NOSESSION,
or whatever). Or, much simpler, to prevent WITH REPLICATION roles from issuing
SQL commands altogether. That'd achieve your goal just as well and is way less
confusing.
best regards,
Florian Pflug