Rob Crittenden wrote: > Simo Sorce wrote: >> On Wed, 2014-06-11 at 17:03 -0400, Rob Crittenden wrote: >>> 0001 >>> >>> When is_allowed_to_access_attr() fails it should include the value of >>> access in the error log for debugging. >> >> Ok added more detailed logging >> >>> Nit: Coluld not fetch REALM backend >> >> Fixed >> >>> There are still a ton of "ber_scanf failed" duplicated fatal errors. I'm >>> fine keeping a common err_msg but the fatal error should be unique. >> >> Yeah thanks to this comment, I had a small change of heart. >> Instead of sending such detailed information to clients I reverted to >> send a little less information to the clients and instead LOG_FATAL in a >> more detailed way. HTH >> >>> This breaks normal host delegation. If you add a host to another host's >>> managedby, getting the keytab will fail. This is due to: >>> >>> [11/Jun/2014:16:56:45 -0400] NSACLPlugin - conn=4 op=3 (main): Deny >>> write on >>> entry(fqdn=client2.example.com,cn=computers,cn=accounts,dc=example,dc=com).attr(ipaProtectedOperation;write_keys) >>> to fqdn=client1.example.com,cn=computers,cn=accounts,dc=example,dc=com: >>> no aci matched the subject by aci(97): aciname= "Groups allowed to >>> create keytab keys", acidn="cn=accounts,dc=example,dc=com" >> >> Ok this should be working now, I added a new ACI to allow also >> managedby#USERDN to operate on keytabs. >> >> New patches attached. > > Functionally these seem to work ok. I think there should be some > documented way to enable the -r in ipa-getkeytab. Right now I'm not even > entirely sure how one would add a permission to do so.
NACK Simo noticed that the ACIs are in cn=accounts. On the one hand this is a reasonable place to put these, on the other it is a bit broad. I think we'll need type-specific ACIs in a number of subtrees: users, computers and services. rob _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
