[Freeipa-devel] [PATCH 0002] Port from python-krbV to python-gssapi

Simo Sorce simo at redhat.com
Fri Jul 31 18:20:44 UTC 2015


On Fri, 2015-07-31 at 16:41 +0200, Michael Šimáček wrote:
> On 2015-07-31 07:52, Jan Cholasta wrote:
> > Hi Michael,
> >
> > Dne 29.7.2015 v 10:09 Michael Šimáček napsal(a):
> >> Hi,
> >>
> >> this is the first attempt to port FreeIPA from deprecated
> >> python3-incompatible python-krbV library to python-gssapi. The patch
> >> depends on python-kerberos->python-gssapi patch [1] to apply cleanly,
> >> but the overlap is small, so I think it can be at least partially
> >> reviewed without it.
> >>
> >> Comments:
> >> I removed Backend.krb and KRB5_CCache classes as they were wrappers
> >> around krbV classes. I added few utility functions to krb_utils module
> >> that perform part of its functionality (no need for classes, because
> >> gssapi acquire calls don't pass any context objects, they wouldn't have
> >> any state).
> >>
> >> I merged the two different kinit_keytab functions.
> >>
> >> GSSAPI doesn't provide any method (that I'm aware of) to get default
> >> ccache name. In most cases this is not needed as we can simply not pass
> >> any name and it will use the default. The ldap plugin had to be adjusted
> >> for this - the connect method now takes new use_gssapi argument, which
> >> can turn on gssapi support without the need to supply explicit ccache
> >> name. The only place where the ccache name is really needed is the test
> >> server, where I use system klist command to obtain it.
> >
> > I would prefer if the semantics were the same as in IPAdmin, i.e. GSSAPI
> > is used by default if bind password is not specified, see
> > IPAdmin.do_bind() in ipapython.ipaldap.
> 
> Just to clarify, the current flow in ldap module is:
> if ccache: # I added "or use_gssapi" here in this patch
>      gssapi_bind
> elif autobind:
>      external_bind
> else:
>      simple_bind

I had to make this change as well for my replica promotion code, and
incidentally used the same indicator "use_gssapi".

> and you would like it to be changed into:
> if bind_pw:
>      simple_bind
> elif autobind:
>      external_bind
> else:
>      gssapi_bind
> 
> Is that correct?

I think this is what Jan wanted, but I am wondering if it is the right
thing to do. In ipa we have basically 2 possible default approaches.
One is to use GSSAPI, and one is to use LDAPI with external bind.

The latter makes sense mostly only when running as root, so I am
wondering, should the default change depending on whether we are root
and we are connecting to the local LDAP server ?

If this is a sensible option it means we have to preserver use_gssapi as
we may need to force use of gssapi in some case even when we are root
and connectiong to the local server (for example to test that the local
ccache can successfully be used).

Jan,
what do you think ?

> >
> >>
> >> It's also not possible to directly get default realm name, what I do is
> >> importing nonexistent name, cannonicalizing it and extracting the realm
> >> from it. Which should work but is ugly. It would be better if we could
> >> modify the places that use it to not need it at all, but it's mostly
> >> used in ldap code and I don't understand that part of FreeIPA.
> >> Alternative would be parsing /etc/krb.conf.
> >
> > You should use api.env.realm where possible. I think this should be most
> > of the places where default realm is currently used, if not all of them.
> 
> That would be great if all the usages could be replaced. How can I 
> determine where api.env.realm can be used? In particular, I'm unsure 
> about ipapython/config.py/__discover_config and ipaserver/plugins/join.py.

try:
	realm = api.env.realm
except:
	realm = dirty gssapi trick ?

Simo.

> >
> >>
> >> Sorry for long patch, but I'm afraid it cannot be reasonably split.
> >>
> >>
> >> Ticket:
> >> https://fedorahosted.org/freeipa/ticket/5164
> >>
> >> [1] https://fedorahosted.org/freeipa/ticket/5147
> >
> > Honza
> >
> 
> Michael
> 


-- 
Simo Sorce * Red Hat, Inc * New York




More information about the Freeipa-devel mailing list