In ca_add.pre_callback, we have:

  if not ldap.can_add(dn[1:]):
      raise ACIError(...)

`can_add' uses the GetEffectiveRights control to see what rights the
user has.

When a user with the 'System: Add CA' permission attempts to add a
CA, the above ACIError gets raised.  This is definitely a bug.  I
think it is a bug in DS GetEffectiveRights code.

The ACI in play is:

  dn: cn=cas,cn=ca,dc=ipa,dc=local
  aci: (targetfilter = "(objectclass=ipaca)")(version 3.0;acl "permission:System
    : Add CA";allow (add) groupdn = "ldap:///cn=System: Add 

The user definitely has the right membership:

  dn: uid=alice,cn=users,cn=accounts,dc=ipa,dc=local
  memberof: cn=ipausers,cn=groups,cn=accounts,dc=ipa,dc=local
  memberof: cn=CA Administrator,cn=roles,cn=accounts,dc=ipa,dc=local
  memberof: cn=LWCA Administration,cn=privileges,cn=pbac,dc=ipa,dc=local
  memberof: cn=System: Add CA,cn=permissions,cn=pbac,dc=ipa,dc=local

William suggested I check whether direct vs. indirect membership
made a difference.  It does not.

A wild guess is that the algorithm that computes whether the subject
has add access under the given entry does not take the targetfilter
into account.  To solve, perhaps we could ignore ACI targetfilter when
computing add access for GER.

Alternatively, is there another way for a user to determine if they
can add an entry at a particular place, without actually doing the


Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA:

Reply via email to