Re: [SOLVED] Re: pgAdmin 4 + python wheel + kerberos - Mailing list pgadmin-support

Greetings Peter,

* Peter (pmc@citylink.dinoex.sub.org) wrote:
> Getting back to this one - sorry, took me a while...

Yeah, same. :)

> On Wed, Jan 15, 2020 at 10:02:26AM -0500, Stephen Frost wrote:
> ! Glad to hear it!  Would love to have the specific details of what you
> ! did to make it work posted to this list or otherwise publicized, for
> ! others who are interested.
>
> Alright.

Thanks for this!

>  Now back to the KRB5CCNAME problem:
>
>     There seems to be no way to tell postgreSQL which credentials
>     to use for connecting (when invoking the client - lib or
>     executable), except this environment variable. (At least I found
>     no other.)

So..  libpq is just calling into the Kerberos libraries and that's what
is actually reading KRB5CCNAME, and I think you're right, you can't pass
that info from libpq to the Kerb libraries today- but we could change
that in libpq, possibly.

For now tho...

>     What can be done: let the web rig drop the creds into a
>     file named by the principal that we got credentials for.(*)

Right.

>     Then, within pgadmin4, we see the "REMOTE_USER" in the request
>     variables set to the same name - so we know the filename.

Sure.

>     There seem to be only two places where pgadmin4 calls to
>     postgres - one is for invocations of externals programs (i.e.
>     forking), and that is simple because we can give a dedicated
>     environment to these, and that should be safe.
>
>     The other is a call to psycopg2.connect() - and I don't know
>     what exactly that does. Anyway, I put the proper KRB5CCNAME
>     into the environment before this call.

Makes sense to me.

>     Then I do a lock around that fork, and around that connect(),
>     so that no two threads can run thru these regions at the same
>     time.
>     I assume this should be safe, and during invocations of postgres
>     the KRB5CCNAME should always point to the credentials of the
>     acting REMOTE_USER.

Any chance you could share that patch..?  Considering that pgAdmin4 has,
sadly, decided to go the (broken) route of adding LDAP basic-user auth,
it'd really be good to, out of the box, make it support Kerberos-based
auth, even with the limitations you've described here.

>   Things I am not completely certain about:
>
>   * I assume that the credentials are only used during the connect
>     (as afterwards the connection is authenticated and they shouldn't
>     have any use anymore for that connection).

Not sure on this- hopefully a pgAdmin4 dev can answer, but it seems
likely to me.

>   * There may be occasions when the database is connected independent
>     of a user action from the web. I doubt that this is the case,
>     because pgadmin would need to ask for the database password at
>     that point, but I didn't analyze the code.
>     In that case there would be no REMOTE_USER information (or a wrong
>     one, which is worse).

Ditto on this one.

>   * There is a feature called "async", or PQconnectStart(). This seems
>     to return *before* the connection is made, i.e. before the
>     KRB5CCNAME from the environment is consumed. But at least for now
>     it also seems that pgadmin does explicitely wait after this call
>     until the connection is established, so that this wait can be
>     included in the locked region.

Maybe not ideal, but doesn't seem that bad.

>   * There is a feature called pgAgent, which does some scheduled
>     tasks, by whatever means. I didn't look into that, I have no idea
>     how that would authenticate to the database, but it certainly does
>     not work with my scheme.

This would need its own Kerberos princ and then to have k5start running
to pull out tickets for it in an ongoing manner and then whatever
process is handling the pgAgent stuff would set its KRB5CCNAME to that
credential cache.

>   (*) I didn't like the idea of creating a file everytime; since this
>     staye in the same process, it would be more appropriate to
>     handover the cred in memory. But it would be difficult to pull
>     them out of the kerberos library, and there seems no way to pass
>     them on to postgres library.

I'd certainly be interested in improving on this situation...

>     So I considered modifying this thing for the purpose:
>     https://www.freebsd.org/cgi/man.cgi?query=kcm
>     But I could not get that running even in its normal operation.

That's too bad as it does look pretty interesting.

>     So for now I do compare the received credential with the one in
>     the file, and write only if they are different.

Not sure about this part..?

> So far, thats the storyline. Enjoy.

Any chance you could share the patch..?

Thanks!

Stephen