James Hogarth wrote:

On 1 August 2013 09:36, Martin Kosek <mko...@redhat.com
<mailto:mko...@redhat.com>> wrote:

    The patch for this would do basically this:
    - remove the following aci:
    (targetattr != aci)(version 3.0; aci "replica admins read access";
    allow (read,
    search, compare) groupdn = "ldap:///cn=Modify Replication
    ... from installer and from LDAP as it is too general
    - add new permission ACI like this:
    3.0; acl "permission:Read Replication Agreements"; allow (read, search,
    compare) groupdn = "ldap:///cn=Read Replication
    - make sure that "Replication Administrators" privilege has it assigned.

    I created an upstream ticket to track this effort:

Reading the upstream documentation I'm wondering if it'd be sensible to
include an additional ACI in replica-acis.ldif of:
changetype: modify
add: aci
aci: (targetattr=dn nsDS5ReplConflict
3.0; aci "conflict read access"; allow (read, search, compare) groupdn =
"ldap:///cn=Read Replication Agreements,cn=permissions,cn=pbac,$SUFFIX";)

 From the upstream documentation here:

This would allow a user with Read Replication Agreements permission to
be able to search for conflicts or tombstone records which would seem
sane from a monitoring point of view...

What do you think?

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 https://fedorahosted.org/freeipa/ticket/1025

Also just to confirm the only thing I need to do with ACIs like this is
to update the ldif (delegation.ldif and replica-acis.ldif) with the new
role/privilege/permission and acis in install/share for the new installs
and add an appropriate entry (not quite ldif) in install/updates to
update the default schema of those updating in future, given no new
attributes - right?

You'll need to create a .update file in install/updates to modify an existing installation.


Freeipa-users mailing list

Reply via email to