В Срд, 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
