On Dec24, 2010, at 04:16 , Tom Lane wrote: > Florian Pflug <f...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
