<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 August 2013 15:55, Rob Crittenden <span dir="ltr"><<a href="mailto:rcritten@redhat.com" target="_blank">rcritten@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">James Hogarth wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
<br>
On 1 August 2013 09:36, Martin Kosek <<a href="mailto:mkosek@redhat.com" target="_blank">mkosek@redhat.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:mkosek@redhat.com" target="_blank">mkosek@redhat.com</a>>> wrote:<br>
<br>
<br>
The patch for this would do basically this:<br>
- remove the following aci:<br>
(targetattr != aci)(version 3.0; aci "replica admins read access";<br>
allow (read,<br>
search, compare) groupdn = "ldap:///cn=Modify Replication<br>
Agreements,cn=permissions,cn=<u></u>pbac,$SUFFIX";)<br>
... from installer and from LDAP as it is too general<br>
- add new permission ACI like this:<br>
(targetattr=*)(targetfilter="(<u></u>|(objectclass=nsds5Replica)(<u></u>objectclass=<u></u>nsds5replicationagreement)(<u></u>objectclass=<u></u>nsDSWindowsReplicationAgreemen<u></u>t)(objectClass=nsMappingTree))<u></u>")(version<br>
3.0; acl "permission:Read Replication Agreements"; allow (read, search,<br>
compare) groupdn = "ldap:///cn=Read Replication<br>
Agreements,cn=permissions,cn=<u></u>pbac,$SUFFIX";)<br>
- make sure that "Replication Administrators" privilege has it assigned.<br>
<br>
I created an upstream ticket to track this effort:<br>
<a href="https://fedorahosted.org/freeipa/ticket/3829" target="_blank">https://fedorahosted.org/<u></u>freeipa/ticket/3829</a><br>
<br>
<br>
Reading the upstream documentation I'm wondering if it'd be sensible to<br>
include an additional ACI in replica-acis.ldif of:<br>
dn: $SUFFIX<br>
changetype: modify<br>
add: aci<br>
aci: (targetattr=dn nsDS5ReplConflict<br>
nsUniqureID)(targetfilter="(|(<u></u>objectclass=nsTombstone)(<u></u>nsDS5ReplConflict=*))")((<u></u>version<br>
3.0; aci "conflict read access"; allow (read, search, compare) groupdn =<br>
"ldap:///cn=Read Replication Agreements,cn=permissions,cn=<u></u>pbac,$SUFFIX";)<br>
<br>
From the upstream documentation here:<br>
<a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Configuration_Command_and_File_Reference/index.html#Replication_Attributes_under_cnreplica_cnsuffixName_cnmapping_tree_cnconfig" target="_blank">https://access.redhat.com/<u></u>site/documentation/en-US/Red_<u></u>Hat_Directory_Server/9.0/html-<u></u>single/Configuration_Command_<u></u>and_File_Reference/index.html#<u></u>Replication_Attributes_under_<u></u>cnreplica_cnsuffixName_<u></u>cnmapping_tree_cnconfig</a><br>
<br>
This would allow a user with Read Replication Agreements permission to<br>
be able to search for conflicts or tombstone records which would seem<br>
sane from a monitoring point of view...<br>
<br>
What do you think?<br>
</div></div></blockquote>
<br>
I think this would be a separate issue. Being able to find the conflicting issues leads directly to the question "what do I do with them?" That is ticket <a href="https://fedorahosted.org/freeipa/ticket/1025" target="_blank">https://fedorahosted.org/<u></u>freeipa/ticket/1025</a><div class="im">
<br></div></blockquote><div><br></div><div>Thanks Rob - I think it worthwhile adding the permissions in place to at least find them as a 'quick win' as it were ... </div><div><br></div><div>What to do after that is an interesting question and would probably take a fair chuck of work to make it nicely visible plus show ways to resolve it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also just to confirm the only thing I need to do with ACIs like this is<br>
to update the ldif (delegation.ldif and replica-acis.ldif) with the new<br>
role/privilege/permission and acis in install/share for the new installs<br>
and add an appropriate entry (not quite ldif) in install/updates to<br>
update the default schema of those updating in future, given no new<br>
attributes - right?<br>
</blockquote>
<br></div>
You'll need to create a .update file in install/updates to modify an existing installation.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>That's great - I had a look through the README in there and looking at other similar bits appears to be fairly simple.</div><div><br></div></div></div></div>