В Срд, 11/01/2012 в 17:06 +0700, Ivan Shmakov пишет:
> >>>>> Denis Feklushkin <denis.feklush...@gmail.com> writes:
> >>>>> В Срд, 11/01/2012 в 13:44 +0700, Ivan Shmakov пишет:
> >>>>> Denis Feklushkin <denis.feklush...@gmail.com> writes:
> 
> […]
> 
>  >>> Libpq often used for connect to the database without human assist.
>  >>> In this case there is no opportunity to enter a password and get a
>  >>> ticket for authentication in Kerberos.
> 
>  >>> Please add the ability to specify in a function
>  >>> PQconnectdb(conninfo) path to the Kerberos 5 keytab file.
> 
>  >> Shouldn't libpq just assume whatever identity confirmed by the prior
>  >> kinit(1) invocation when using Kerberos for authentication?
> 
>  > In general, ability to use a different keytab files would add some
>  > flexibility - libpq will be able to connect to the different servers
>  > in different realms at same time.  (I wanted it in 2009, as far as I
>  > can remember)
> 
>       Please note that it's possible to store keys for multiple
>       Kerberos identities in a single keytab file.

Of course.

> 
>       Also, it's possible to make Kerberos KDC's for different realms
>       trust each other.  Then, the client having an identity within,
>       say, the EXAMPLE.ORG realm could authenticate to the server
>       within, say, EXAMPLE.COM.
> 

Suppose I am the developer of databases on different servers in
different realms. How do I connect to them at the same time?

On the other hand, the same question holds for any other servers (ftpd
etc), I guess. And it means that the problem is not in the libpq -
Kerberos is not allow this, it cannot get multiple tickets for different
realms. (By the way, it's strange that Kerberos did not care about it)

That's how I see answer for my question in 2012.

>       Note, however, that this doesn't automatically give any
>       EXAMPLE.ORG users the /authorization/ to use EXAMPLE.COM
>       services.
> 
>  > But if this behavior violates ideology of the Kerberos then this
>  > option is not necessary.
> 
>       I doubt for the ideology, but such an option is likely to
>       introduce extra burden for every client for which such an option
>       is desired.
> 

Yes.

>       In particular, it's likely that for the clients with GUI it'd be
>       necessary to introduce an extra “File open” dialog so that
>       keytab file (or files) could then be specified by the user.
> 

Yes!

This problem is not in libpq, I think we can close this issue.

>  >> And, kinit(1) (as of heimdal-clients, 1.4.0~git20100726.dfsg.1-1+b1)
>  >> will accept a keytab file, like:
> 
>  >> $ kinit --keytab="$HOME"/.my.keytab --use-keytab \
>  >>       my/ident...@realm.example.org 
> 
>  >> (Though I haven't actually tested the above.)
> 
>  > Confirmed, Heimdal's kinit with -t option works fine.
> 
>       … Is libpq then able to use these credentials?
> 

Yes.





-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to