ldapbindpasswdfile

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ldapbindpasswdfile

Thomas Munro-5
Hello hackers,

Some users don't like the fact that ldapbindpasswd can leak into logs
(and now system views?).  Also, some users don't like the fact that it
is in cleartext rather than some encryption scheme (though I don't
know what, since we'd presumably also need the key).  I propose a new
option $SUBJECT so that users can at least add a level of indirection
and put the password in a file.  A motivated user could point it at an
encrypted loopback device so that they need a passphrase at mount
time, or a named pipe that performs arbitrary magic.  Some of these
topics were discussed last time someone had this idea[1].

Using a separate file for the bind password is fairly common in other
software: see the ldapsearch's -y switch, and I think it probably
makes sense at the very least as a convenience, without getting into
hand-wringing discussions about whether any security is truly added.

Draft patch attached.

Hi Stephen!

I also know that a motivated user could also use GSSAPI instead of
LDAP.  Do you think we should update the manual to say so, perhaps in
a "tip" box on the LDAP auth page?

[1] https://www.postgresql.org/message-id/flat/20140617175511.2589.45249%40wrigleys.postgresql.org

--
Thomas Munro
https://enterprisedb.com

0001-Add-ldapbindpasswdfile-option-for-pg_hba.conf.patch (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ldapbindpasswdfile

Thomas Munro-5
On Tue, May 14, 2019 at 1:49 PM Thomas Munro <[hidden email]> wrote:
> ... or a named pipe that performs arbitrary magic.

(Erm, that bit might not make much sense...)

--
Thomas Munro
https://enterprisedb.com


Reply | Threaded
Open this post in threaded view
|

Re: ldapbindpasswdfile

Daniel Gustafsson
In reply to this post by Thomas Munro-5
> On 14 May 2019, at 03:49, Thomas Munro <[hidden email]> wrote:

> I propose a new option $SUBJECT so that users can at least add a level of
> indirection and put the password in a file.


+1, seems like a reasonable option to give.

> Draft patch attached.

I might be a bit thick, but this is somewhat hard to parse IMO:

+        File containing the password for user to bind to the directory with to
+        perform the search when doing search+bind authentication

To add a little bit more security around this, does it make sense to check (on
unix filesystems) that the file isn’t world readable/editable?

+   fd = OpenTransientFile(path, O_RDONLY);
+   if (fd < 0)
+       return -1;

cheers ./daniel