On Fri, 2014-06-20 at 16:50 -0400, Nathaniel McCallum wrote:
> On Fri, 2014-06-20 at 16:05 -0400, Simo Sorce wrote:
> > On Fri, 2014-06-20 at 14:47 -0400, Nathaniel McCallum wrote:
> > > This change would have very small impact on your patch set, but would
> > > be
> > > much clearer for the future consumers of this protocol. Code can be
> > > changed; protocols can't.
> > Ok this new patchset implements the requested change.
> > Initial testing seem to indicate it all works as expected.
> 0001: Line 555 has very wrong indentation.
> Other than that, I have looked over 0001 and 0002 very closely and built
> and tested them. Everything works. So conditional (indent fix) ACK on
> both of these. I don't see any reason to avoid merging these as soon as
> the indent fix is completed. It should substantially reduce your
> differential from master.
> In the new ASN.1, "Newkeys" has the wrong capitalization. This affects
> patches 0003 and 0005.
> I think patch 0003 may still have a permissions problem. For instance,
> this works for me with no error:
> $ ipa user-find --whoami
> 1 user matched
> User login: admin
> Last name: Administrator
> Home directory: /home/admin
> Login shell: /bin/bash
> UID: 1569600000
> GID: 1569600000
> Account disabled: False
> Password: True
> Kerberos keys available: True
> Number of entries returned 1
> $ ipa-getkeytab -s ipa.example.com -p foo/ipa.example.com -r -k bar
> Keytab successfully retrieved and stored in: bar
> Is that really correct behavior or did I screw something up? I thought
> we had restricted the admin user from reading keys without changing
Can you check if ipaProtectedOperation is in the aci attribute in the
base tree object ?
It should be there as excluded, and that should cause admin to not be
able to retrieve keytabs.
Simo Sorce * Red Hat, Inc * New York
Freeipa-devel mailing list