Re: BUG #10680: LDAP bind password leaks to log on failed authentication
От | Tom Lane |
---|---|
Тема | Re: BUG #10680: LDAP bind password leaks to log on failed authentication |
Дата | |
Msg-id | 26135.1413144596@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #10680: LDAP bind password leaks to log on failed authentication (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: BUG #10680: LDAP bind password leaks to log on failed
authentication
|
Список | pgsql-bugs |
Stephen Frost <sfrost@snowman.net> writes: > Let's stop having passwords and secrets in a complex configuration file > which can have parsing and other failures. > How about allowing users to put that information in an independent file, > as do for SSL (admittedly, probably more because it's easier for us to > deal with OpenSSL that way, but still)? And then what? This other file can't possibly be so simple that it's immune to having syntax errors, for example. You're just moving the same problems from point A to point B. More, this would complicate configuration and thereby create a whole new set of possible config errors, which we'd then feel pressure to ameliorate by adding more logging showing what the postmaster is doing. And that logging would have this same issue of maybe it's exposing information that person A doesn't want logged ... even though person B needs that very same info to help him figure out his configuration mistake. A likely example of that is feeding the wrong password/secret to some auth infrastructure service, because you referenced the wrong item in this secondary file. The core problem here is that we *need* to put security-relevant info into the postmaster log in order to help people resolve problems. Moving around configuration details isn't going to fix that; indeed, the more complicated the configuration files, the worse the problem will be. regards, tom lane
В списке pgsql-bugs по дате отправления: