Re: [Freeipa-devel] gssproxy-0.6.2-2 broken

[Robbie Harwood]

Standa Laznicka  writes:

> Hello,
>
> Current gssproxy in Fedora 25 "updates" repository (gssproxy-0.6.2-2) is 
> broken. For a freshly-installed IPA server, the infamous error
>
> "ipa: ERROR: Major (851968): Unspecified GSS failure.  Minor code may 
> provide more information, Minor (2598845123): No credentials cache 
> found" will appear. 100% reproducible.
>
> Please use the gssproxy-0.6.2-1 from @freeipa/freeipa-master repository 
> instead. Note that downgrade + gssproxy service restart works.

Hi, thanks for letting us know.  In the future it would be better to
provide negative karma to the update and file a bugzilla.

Please try gssproxy-0.6.2-4 from updates, and hopefully it will work
better for you.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] FedoraHosted.org sunset

[Robbie Harwood]

Nathaniel McCallum  writes:

> On Fri, 2016-09-30 at 14:19 +0200, Martin Kosek wrote:
>> On 09/23/2016 09:54 AM, Jakub Hrozek wrote:
>>> On Thu, Sep 22, 2016 at 06:09:43PM +0200, Petr Vobornik wrote:

 As you know, FedoraHosted.org will be decommissioned.
  https://communityblog.fedoraproject.org/fedorahosted-sunset-2017
 -02-28/
 
 We use Trac instance there. Let's discuss where we should migrate
 and what are our requirements. Then put results on one place. For
 that I've created:  
 http://www.freeipa.org/page/FedoraHosted_Migration
>>> 
>>> 
>>> That you for writing this up, there are some good points I didn't
>>> think about, like migrating the ticket numbers. Did you already file
>>> an issue that tracks this in Pagure (or asked if this is already
>>> possible)?
>> 
>> 
>> I think the achieving the same ticket numbers should not be
>> difficult. During the migration, we would just need to make sure we
>> insert dummy Pagure/Github/... tickets on when the original ticket
>> was deleted, like
>> 
>> https://fedorahosted.org/freeipa/ticket/2
>
> A pro for github is that migration tools exist. This is a con for
> pagure.

Much as I want github... a migration tool does exist to go to pagure:
https://pagure.io/pagure-importer/ I have used it (on the gssproxy
fedorahosted as a test) and while I did not like it it did get the job
done eventually.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf

[Robbie Harwood]

Alexander Bokovoy <aboko...@redhat.com> writes:

> On Sat, 28 May 2016, Robbie Harwood wrote:
>> Alexander Bokovoy <aboko...@redhat.com> writes:
>>> On Fri, 27 May 2016, Robbie Harwood wrote:
>>>> Stanislav Laznicka <slazn...@redhat.com> writes:
>>>>> From: Stanislav Laznicka <slazn...@redhat.com>
>>>>>
>>>>> The include of /etc/krb5.conf.d/ is required for crypto-policies
>>>>> to work properly
>>>>>
>>>>> https://fedorahosted.org/freeipa/ticket/5912
>>>>
>>>> Thank you for working on this.  Is the intent on the part of
>>>> FreeIPA to keep a separate, freeipa-speicifc directory?  And if so,
>>>> can I suggest that we not do that?
>>>
>>> SSSD cannot write to /etc and I don't think we have to change it.
>>
>> Can you elaborate on this?  Why can't sssd write the stuff it puts in
>> /var/lib into /etc, or symlink it?
>
> Writing to /etc is considered a privilege of a system administrator. A
> runtime override is typically done outside it, in /run like systemd
> allows for its configuration for volatile setups and in /var/lib
> for non-volatile ones. The latter has long been a state of affairs in
> Linux.
>
> Currently SSSD runs under root but it is already made possible to run as
> non-root user and we intend to switch to that mode in future releases.

I guess I don't see a meaningful difference here.  We're still writing
to /etc when we modify krb5.conf.

My reading of the FHS is that this is not an intended use of /var/lib:
/var/lib is for state information [0], and the only time the FHS
mentions config files is to point out that they go in the /etc tree.

Anyway, I've said my piece and won't derail this further.  If you want
to merge, this is a cosmetic issue and I can live with it.

[0]: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf

[Robbie Harwood]

Alexander Bokovoy <aboko...@redhat.com> writes:

> On Fri, 27 May 2016, Robbie Harwood wrote:
>>Stanislav Laznicka <slazn...@redhat.com> writes:
>>
>>> From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001
>>> From: Stanislav Laznicka <slazn...@redhat.com>
>>> Date: Fri, 27 May 2016 16:12:31 +0200
>>> Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf
>>>
>>> The include of /etc/krb5.conf.d/ is required for crypto-policies to work 
>>> properly
>>>
>>> https://fedorahosted.org/freeipa/ticket/5912
>>
>> Thank you for working on this.  Is the intent on the part of FreeIPA to
>> keep a separate, freeipa-speicifc directory?  And if so, can I suggest
>> that we not do that?
>
> Which directory are you talking about? /var/lib/sss/pubconf/krb5.include.d/?

Yes, this one.

> SSSD cannot write to /etc and I don't think we have to change it.

Can you elaborate on this?  Why can't sssd write the stuff it puts in
/var/lib into /etc, or symlink it?


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH 0037] Added /etc/krb5.conf.d/ to krb5.conf

[Robbie Harwood]

Stanislav Laznicka  writes:

> From 7a55f169181ab8647cd2d919f35c004b14d5bc7f Mon Sep 17 00:00:00 2001
> From: Stanislav Laznicka 
> Date: Fri, 27 May 2016 16:12:31 +0200
> Subject: [PATCH] Added krb5.conf.d/ to included dirs in krb5.conf
>
> The include of /etc/krb5.conf.d/ is required for crypto-policies to work 
> properly
>
> https://fedorahosted.org/freeipa/ticket/5912

Thank you for working on this.  Is the intent on the part of FreeIPA to
keep a separate, freeipa-speicifc directory?  And if so, can I suggest
that we not do that?


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Improving bug reporting

[Robbie Harwood]

Lukas Slebodnik <lsleb...@redhat.com> writes:

> On (03/05/16 12:29), Robbie Harwood wrote:
>>David Kupka <dku...@redhat.com> writes:
>>
>>> --8<- trac-ticket-template-proposal --->8--
>>> Related SW versions:
>>> On server:
>>> {{{
>>> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server 
>>
>> I think this is a good idea.  However, we are on Debian/family as
>> well now, and I think we want to accept bugs that come from these
>> users as well.
>
> FreeIPA is heavily patched on debian and has quite old version there
> 4.0.5.
>
> The better would be recommend to reproduce with upstream version
> (fedora/CentOS).

(FreeIPA 4.1.4 is available on Debian, but your point still stands.)

In summary: I don't like that upstream is conflated with fedora/CentOS.
Of course I understand that this was done to ease development and not
out of malice.  But longer term I would like Debian/Ubuntu FreeIPA to be
less of an afterthought because I believe we can attract users to our
product.  I believe this to be especially true with working
freeipa-client on those distros, which we now have and I am very happy
about.

Ultimately, it's not a huge issue.  Users who are able to build from
source very likely also know their package manager and how to translate
the invocations.  And if they're not building from source, then the bug
should go downstream first regardless.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Improving bug reporting

[Robbie Harwood]

David Kupka  writes:

> --8<- trac-ticket-template-proposal --->8--
> Related SW versions:
> On server:
> {{{
> $ rpm -q freeipa-server pki-base 389-ds-base bind samba krb5-server 
> certmonger
> }}}
> On client:
> {{{
> $ rpm -q freeipa-client krb5-workstation certmonger
> }}}

I think this is a good idea.  However, we are on Debian/family as well
now, and I think we want to accept bugs that come from these users as
well.  So, in the interest of completeness, I believe the corresponding
invocations are:

> $ dpkg-query -W freeipa-server pki-base 389-ds-base bind9 samba \
> krb5-kdc krb5-admin-server krb5-kpropd

Note the split on the krb5 packaging; depending on what piece(s) you're
checking for in the RPM krb5-server, this list is probably reducible.

> $ dpkg-query -W freeipa-client krb5-user certmonger

To give an example of what output of these looks like, here's a run of
the server command on a machine that's missing some packages:

> rharwood@thriss:~$ dpkg-query -W freeipa-server pki-base 389-ds-base \
> bind9 samba krb5-kdc krb5-admin-server krb5-kpropd
> bind9
> krb5-admin-server   1.13.2+dfsg-5
> krb5-kdc1.13.2+dfsg-5
> samba   2:4.3.8+dfsg-1
> dpkg-query: no packages found matching freeipa-server
> dpkg-query: no packages found matching pki-base
> dpkg-query: no packages found matching 389-ds-base
> dpkg-query: no packages found matching krb5-kpropd
> rharwood@thriss:~$ 

i.e., it has bind9, krb5-admin-server, krb5-kdc, and samba, but is
missing the rest of the requested packages.

Thanks,
--Robbie


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [TEST][patch-0032] Added a kdestroy call to clean ccache

[Robbie Harwood]

Rob Crittenden  writes:

> Would it be more robust to call kdestroy -A or is that just overkill in 
> this case?

I believe it would be superior to call `kdestroy -A`, yes.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Jan Cholasta jchol...@redhat.com writes:

 On 25.8.2015 12:46, Michael Šimáček wrote:
 On 2015-08-25 12:38, Alexander Bokovoy wrote:
 On Tue, 25 Aug 2015, Michael Šimáček wrote:
 On 2015-08-24 20:29, Robbie Harwood wrote:
 Michael Šimáček msima...@redhat.com writes:
 On 2015-08-24 17:49, Simo Sorce wrote:
 On Mon, 2015-08-24 at 17:18 +0200, Michael Šimáček wrote:
 On 2015-08-24 14:50, Jan Cholasta wrote:

 Fixed. python-gssapi has a display_as method that could pull the
 name
 from it, but it doesn't work in current version, therefore using
 partition to split on '@'

 It's actually a bug in MIT Krb5, as we noted in your bug[0].  So this:

 -user = api.Command.user_show(unicode(principal[0]))['result']
 +user =
 api.Command.user_show(principal.partition('@')[0])['result']

 is working around a bug in specific Kerberos versions.  If people are
 okay with merging such code, then I guess this is fine; I would
 personally not do so because there is not a clear point at which it can
 be removed.  At the very least, we should wait until we see what
 versions of krb5 MIT is going to fix.

 Otherwise, looks good.

 [0]: https://github.com/pythongssapi/python-gssapi/issues/79


 python-krbV migration is blocking support for Python 3. The bug
 doesn't have any fix upstream yet and there are two bugs actually, the
 second one is in python-gssapi, which I've just reported [1]. Waiting
 for two bugs to be fixed could be detrimental to py3 migration as we
 don't have much time left. And I'm no longer sure that display_as

 I don't buy this.

 We have plenty of time for solving these bugs. Remember, that Samba
 DCE RPC bindings aren't migrated to Python 3 either and will not be
 before release of Samba 4.4. For Samba 4.3 it is simply too late.

 So we are still far away from full Python3 migration for FreeIPA and
 waiting for solving these two bugs is OK.

 If fixing them solves anything at all. I planned to use
 display_as(NameType.user), but when trying it on Name object with
 name_type set (which doesn't trigger the segfault), it doesn't seem to
 work either. I get:
 gssapi.raw.exceptions.OperationUnavailableError: Major (1048576): The
 operation or option is not available or unsupported, Minor (0): Unknown
 error

 Robbie, can you clarify whether display_as could be actually used to get
 the first component of the principal reliably?

display_as should behave in accordance with its docs; anything else is a
bug report, which you filed.  I don't know what you're asking me for
beyond that.

 As I have written in the other thread, we use principal.split('@') in 
 other parts of IPA, so principal.partition('@') should be OK as well.

 This patch works for me, so ACK.

 Unless there are any further objections, I would like to push it.

I think the newest iteration of this

 user = 
 api.Command.user_show(principal.partition('@')[0].partition('/')[0])['result']

is even worse, but if it is decided to merge, then hopefully we can be
rid of it quickly.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 On 2015-08-24 17:49, Simo Sorce wrote:

 On Mon, 2015-08-24 at 17:18 +0200, Michael Šimáček wrote:

 On 2015-08-24 14:50, Jan Cholasta wrote:

 On 23.8.2015 23:27, Michael Šimáček wrote:

 3) ipa-adtrust-install fails with:

 admin password:

 Unrecognized error during check of admin rights:
 ad...@abc.idm.lab.eng.brq.redhat.com: user not found

 Apparently there is a user-show ad...@abc.idm.lab.eng.brq.redhat.com
 call where a user-show admin call should be.

 Fixed. python-gssapi has a display_as method that could pull the name
 from it, but it doesn't work in current version, therefore using
 partition to split on '@'

It's actually a bug in MIT Krb5, as we noted in your bug[0].  So this:

 -user = api.Command.user_show(unicode(principal[0]))['result']
 +user = api.Command.user_show(principal.partition('@')[0])['result']

is working around a bug in specific Kerberos versions.  If people are
okay with merging such code, then I guess this is fine; I would
personally not do so because there is not a clear point at which it can
be removed.  At the very least, we should wait until we see what
versions of krb5 MIT is going to fix.

Otherwise, looks good.

[0]: https://github.com/pythongssapi/python-gssapi/issues/79


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 On 2015-08-20 12:32, Michael Šimáček wrote:

 Michael Šimáček msima...@redhat.com writes:

 Attaching new revision of the patch. Changes from the previous:
 - ldap2's connect now chooses the bind type same way as in ipaldap
 - get_default_realm usages replaced by api.env.realm
 - fixed missing third kinit attempt in trust-fetch-domains
 - removed rewrapping gssapi errors to ccache errors in krb_utils
 - updated some parts of exception handling

 Rebased on top of current master.

 One of the commits reintroduced krbV dependency that I didn't notice. 
 Attaching updated revision. Only changes against previous revision are 
 in files daemons/dnssec/ipa-dnskeysync-replica and 
 daemons/dnssec/ipa-ods-exporter.

This is much better, thanks!  I've got some comments inline.

 +except gssapi.exceptions.GSSError:
  # If there was failure on using keytab, assume it is stale and retrieve 
 again
  retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal)

This code still bothers me a bit, but I think fixing it is probably
beyond the scope of a python-gssapi port.

 +try:
 +creds = get_credentials(name=name, ccache_name=ccache_name)
 +# property access would raise exception if expired
 +if creds.lifetime  0:
 +return creds
 +except gssapi.exceptions.ExpiredCredentialsError:
 +return None

Per rfc2744, lifetime is unsigned.  It's not immediately clear what will
happen when `creds.lifetime == 0`; perhaps an explicit `return Nune` in
that case?

  # Setup LDAP connection
  try:
 -ctx = krbV.default_context()
 -ccache = ctx.default_ccache()
 -api.Backend.ldap2.connect(ccache)
 +api.Backend.ldap2.connect()
  cls.ldap = api.Backend.ldap2
 -except krbV.Krb5Error as e:
 +except gssapi.exceptions.GSSError:
  sys.exit(Must have Kerberos credentials to migrate Winsync 
 users.)

Can you log the error here?  The other places GSSError is being caught
are doing a great job of either filtering-and-raising or
logging-and-exiting, so thanks for fixing those.

 +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache
 +# name, but we don't need it outside test server
 +def get_default_ccache_name():
 +try:
 +out = check_output(['klist'])
 +except CalledProcessError:
 +raise RuntimeError(Default ccache not found. Did you kinit?)
 +match = re.match(r'^Ticket cache:\s*(\S+)', out)
 +if not match:
 +raise RuntimeError(Cannot obtain ccache name)
 +return match.group(1)

Yup, this is still ugly.  Ah well, it's only test code.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Simo Sorce s...@redhat.com writes:

 On Thu, 2015-08-20 at 14:42 -0400, Robbie Harwood wrote:
 Michael Šimáček msima...@redhat.com writes:
 
 On 2015-08-20 12:32, Michael Šimáček wrote:

 Michael Šimáček msima...@redhat.com writes:

 Attaching new revision of the patch. Changes from the previous:
 - ldap2's connect now chooses the bind type same way as in ipaldap
 - get_default_realm usages replaced by api.env.realm
 - fixed missing third kinit attempt in trust-fetch-domains
 - removed rewrapping gssapi errors to ccache errors in krb_utils
 - updated some parts of exception handling

 Rebased on top of current master.

 One of the commits reintroduced krbV dependency that I didn't notice. 
 Attaching updated revision. Only changes against previous revision are 
 in files daemons/dnssec/ipa-dnskeysync-replica and 
 daemons/dnssec/ipa-ods-exporter.
 
 This is much better, thanks!  I've got some comments inline.
 
 +# Ugly hack for test purposes only. GSSAPI has no way to get default ccache
 +# name, but we don't need it outside test server
 +def get_default_ccache_name():
 +try:
 +out = check_output(['klist'])
 +except CalledProcessError:
 +raise RuntimeError(Default ccache not found. Did you kinit?)
 +match = re.match(r'^Ticket cache:\s*(\S+)', out)
 +if not match:
 +raise RuntimeError(Cannot obtain ccache name)
 +return match.group(1)
 
 Yup, this is still ugly.  Ah well, it's only test code.

 Well turns out there is a gssapi_krb5 extension to get a ccache name:
   gss_krb5_ccache_name()

 Robbie,
 do you think we should expose it in python-gssapi if available ?

It doesn't seem dangerous, so I see no reason not to.  It's on our giant
eventually list[0], so we'd definitely be open to it.  I do not have
the cycles for this right now, though I've opened a bug for it[1].

[0]: https://github.com/pythongssapi/python-gssapi/issues/48
[1]: https://github.com/pythongssapi/python-gssapi/issues/75


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 Attaching new revision of the patch. Changes from the previous:
 - ldap2's connect now chooses the bind type same way as in ipaldap
 - get_default_realm usages replaced by api.env.realm
 - fixed missing third kinit attempt in trust-fetch-domains
 - removed rewrapping gssapi errors to ccache errors in krb_utils
 - updated some parts of exception handling

This patch doesn't seem to apply to master.  Can you update it or
indicate what you're patching against?  Thanks!


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 Attaching new revision of the patch that performs the full negotiation
 cycle.

Looks good to me, thanks!


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 On 2015-07-29 19:20, Robbie Harwood wrote:

 Michael Šimáček msima...@redhat.com writes:

 -# The keytab may have stale key material (from older trust-add run)
 -if not os.path.isfile(oneway_ccache_name):
 -oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 -except krbV.Krb5Error as e:
 +try:
 +# The keytab may have stale key material (from older trust-add run)
 +cred = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 +# would raise exception if expired
 +cred.lifetime
 +except gssapi.exceptions.ExpiredCredentialsError:
 +cred = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 +except gssapi.exceptions.GSSError:
   # If there was failure on using keytab, assume it is stale and 
 retrieve again
   retrieve_keytab(api, ccache_name, oneway_keytab_name, 
 oneway_principal)

 In general, it's bad practice to catch *all* possible GSS errors unless
 you intend to display their status and/or abort/raise.  If there's a
 specific state you want to cope with here, catch the exception related
 to it, not all of them.  Up above is a place where I think this is done
 right.

 I haven't found any specific exception for keytab problems, what should 
 I catch?
 But there's a different error, there should be one more attempt to get 
 the credentials there. I'll fix it in the next revision of the patch.

I seem to have misread the nested except blocks, which makes this code
different from the code I thought was similar above it.

I would think the only error that could pop out for keytab problems that
can actually be fixed would be ExpiredCredentialsError, but if you're
seeing more than just that in practice that fetching the keytab again
actually fixes, then I will defer to you.

 Thank you for your feedback, I'll post a next revision of the patch 
 after we clarify how to proceed with the default realm.

Sounds good!


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

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

[Robbie Harwood]

Michael Šimáček msima...@redhat.com writes:

 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.

This is sub-optimal, but not a huge deal if it's only in the test
suite.

 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.

Please try not to do this.  DEFINITELY do not parse krb.conf.
Unfortunately, I do not know enough about the LDAP code to know why this
is needed or to suggest an alternate solution.

 Sorry for long patch, but I'm afraid it cannot be reasonably split.

This is indeed really long and difficult to work through.  I have
probably missed some things; apologies if they come through in a later
round.

 +try:
 +cred = kinit_keytab(principal, keytab_name, ccache_name)
 +# would raise exception if expired
 +cred.lifetime
 +except gssapi.exceptions.ExpiredCredentialsError:
 +# delete stale ccache and try again
 +os.unlink(ccache_name)
 +cred = kinit_keytab(principal, keytab_name, ccache_name)

See next comment.

 -# The keytab may have stale key material (from older trust-add run)
 -if not os.path.isfile(oneway_ccache_name):
 -oneway_ccache = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 -except krbV.Krb5Error as e:
 +try:
 +# The keytab may have stale key material (from older trust-add run)
 +cred = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 +# would raise exception if expired
 +cred.lifetime
 +except gssapi.exceptions.ExpiredCredentialsError:
 +cred = kinit_keytab(oneway_principal, oneway_keytab_name, 
 oneway_ccache_name)
 +except gssapi.exceptions.GSSError:
  # If there was failure on using keytab, assume it is stale and retrieve 
 again
  retrieve_keytab(api, ccache_name, oneway_keytab_name, oneway_principal)

In general, it's bad practice to catch *all* possible GSS errors unless
you intend to display their status and/or abort/raise.  If there's a
specific state you want to cope with here, catch the exception related
to it, not all of them.  Up above is a place where I think this is done
right.

 -ctx = krbV.default_context()
 -ccache = ctx.default_ccache()
 -principal = ccache.principal()
 -except krbV.Krb5Error, e:
 +principal = krb_utils.get_principal()
 +except errors.CCacheError:
  sys.exit(Must have Kerberos credentials to setup AD trusts on 
 server)

Based on how GSSAPI error messages are being packed into CCache errors
(the name of which is itself unfortunate...), it would be nice to give
some hint of the problem here if it were GSSAPI; otherwise, to my eye,
it looks like the GSSAPI status is being dropped.

 +def get_credentials(name=None, ccache_name=None):
  '''
 -Kerberos stores a TGT (Ticket Granting Ticket) and the service
 -tickets bound to it in a ccache (credentials cache). ccaches are
 -bound to a Kerberos user principal. This class opens a Kerberos
 -ccache and allows one to manipulate it. Most useful is the
 -extraction of ticket entries (cred's) in the ccache and the
 -ability to examine their attributes.
 +Obtains GSSAPI credentials with given principal name from ccache. When no
 +principal name specified, it retrieves the default one for given
 +credentials cache.
 +
 +:parameters:
 +  name
 +gssapi.Name object specifying principal or None for the default
 +  ccache_name
 +string specifying Kerberos credentials cache name or None for the
 +default
 +:returns:
 +  gssapi.Credentials object
 +
 +store = None
 +if ccache_name:
 +store = {'ccache': ccache_name}
 +try:
 +return gssapi.Credentials(usage='initiate', name=name, store=store)
 +except gssapi.exceptions.GSSError as e:
 +if e.min_code == KRB5_FCC_NOFILE:
 +raise ValueError('%s, ccache=%s' % (e.message, ccache_name))
 +raise errors.CCacheError()

This is another case where it stands out that the specific error from
GSSAPI should probably be checked.

 +# FIXME this is a temporary workaround. We should find some nicer 
 solution
 +name = gssapi.Name('notempty', gssapi.NameType.user)
 +

Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi

[Robbie Harwood]

Some comments from Solly and I inline:

Michael Šimáček msima...@redhat.com writes:

 On 2015-07-22 15:47, Simo Sorce wrote:
 Comments inline.

 - Original Message -
 From: Michael Simacek msima...@redhat.com
 To: freeipa-devel@redhat.com
 Sent: Tuesday, July 21, 2015 8:02:26 AM
 Subject: [Freeipa-devel] [PATCH] Port from python-kerberos library to   
 python-gssapi

 diff --git a/ipalib/util.py b/ipalib/util.py
 index 649a487..aea3ba9 100644
 --- a/ipalib/util.py
 +++ b/ipalib/util.py
 @@ -63,15 +63,15 @@ def json_serialize(obj):

   def get_current_principal():
   try:
 -import kerberos
 -rc, vc = kerberos.authGSSClientInit(notempty)
 -rc = kerberos.authGSSClientInquireCred(vc)
 -username = kerberos.authGSSClientUserName(vc)
 -kerberos.authGSSClientClean(vc)
 +import gssapi
 +cred = gssapi.raw.acquire_cred(usage='initiate').creds
 +name = gssapi.raw.inquire_cred(cred, lifetime=False, usage=False,
 +   mechs=False).name
 +username = gssapi.raw.display_name(name, name_type=False).name

 Same as above.
 Create a credential and inquire it with the high level api

 Done, but I still use raw.display_name as I don't see how to get it from 
 high-level API (besides parsing repr).

I believe one can call `str()`.  See
http://pythonhosted.org/gssapi/gssapi.html#gssapi.names.Name

 @@ -548,14 +552,12 @@ class KerbTransport(SSLTransport):
  service = HTTP@ + host.split(':')[0]
  
  try:
 -(rc, vc) = kerberos.authGSSClientInit(service=service,
 -  gssflags=self.flags)
 -except kerberos.GSSError, e:
 -self._handle_exception(e)
 -
 -try:
 -kerberos.authGSSClientStep(vc, )
 -except kerberos.GSSError, e:
 +name = gssapi.Name(service, gssapi.NameType.hostbased_service)
 +sec_context = gssapi.SecurityContext(name=name, flags=self.flags)
 +# gssapi defers errors to next step, we want them now
 +sec_context.__DEFER_STEP_ERRORS__ = False

As a class-level flag, this should probably be used as such.  Preferable
to using it would be to check complete, though - is there a reason not
to do that here?

Otherwise, looks good!


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi

[Robbie Harwood]

Michael Simacek msima...@redhat.com writes:

 - Original Message -
 From: Christian Heimes chei...@redhat.com
 To: freeipa-devel@redhat.com, msima...@redhat.com
 Sent: Tuesday, July 21, 2015 2:23:06 PM
 Subject: Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to 
 python-gssapi
 
 On 2015-07-21 14:02, Michael Simacek wrote:
  Hi,
  
  This is a first part of my effort to port FreeIPA from Python3-incompatible
  Kerberos libraries to python-gssapi. This patch should replace
  python-kerberos
  with python-gssapi (both use C GSSAPI behind the scenes).

This looks good to me!  I'm glad the port is progressing well, and
please feel free to contact me if you hit trouble with python-gssapi.


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] Port from python-kerberos library to python-gssapi

[Robbie Harwood]

Michael Simacek msima...@redhat.com writes:

 This is a first part of my effort to port FreeIPA from Python3-incompatible
 Kerberos libraries to python-gssapi. This patch should replace python-kerberos
 with python-gssapi (both use C GSSAPI behind the scenes).

Okay, Solly and I went through this again, and there might be a problem.

 @@ -548,14 +551,9 @@ class KerbTransport(SSLTransport):
  service = HTTP@ + host.split(':')[0]
  
  try:
 -(rc, vc) = kerberos.authGSSClientInit(service=service,
 -  gssflags=self.flags)
 -except kerberos.GSSError, e:
 -self._handle_exception(e)
 -
 -try:
 -kerberos.authGSSClientStep(vc, )
 -except kerberos.GSSError, e:
 +name = gssapi.Name(service, gssapi.NameType.hostbased_service)
 +response = gssapi.raw.init_sec_context(name, 
 flags=self.flags).token
 +except gssapi.exceptions.GSSError as e:
  self._handle_exception(e, service=service)
  
  for (h, v) in extra_headers:
 @@ -564,7 +562,7 @@ class KerbTransport(SSLTransport):
  break
  
  extra_headers.append(
 -('Authorization', 'negotiate %s' % 
 kerberos.authGSSClientResponse(vc))
 +('Authorization', 'negotiate %s' % base64.b64encode(response))
  )

If you call init_sec_context, the token returned may be an error token,
and the error will be deferred until the next use of the context.  This
behavior can be turned off by setting __DEFER_STEP_ERRORS__ to false on
the class.

More information:
https://pythonhosted.org/gssapi/gssapi.html#gssapi.sec_contexts.SecurityContext.step


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code