Re: [Freeipa-devel] GetEffectiveRights and add ACIs

[thierry bordaz]

Hello,

The option specifies the value of 'objectclass' attribute during the 
GER. That is evaluated at attributeLevelRights but not at the 
entryLevelRights. I was not able to fix the test case using this option.

For information I opened that ticket 
https://fedorahosted.org/freeipa/ticket/6609

thanks
thierry

On 01/13/2017 11:01 AM, Ludwig Krispenz wrote:
Hi,

if you look at: 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Viewing_the_ACIs_for_an_Entry-Get_Effective_Rights_Control.html#ex-ger-non-entry

then it looks like you can provide GER a bit of information eg 
objectclass of the new entry, so that the existing aci would be 
selected. Maybe can_add can be extended.

Ludwig

On 01/13/2017 09:12 AM, thierry bordaz wrote:
Hi Fraser,

I failed to reproduce you test case, I mean the aci granted the add 
right to a group member to ADD an entry with the filtered attribute.
Now I have a doubt to test attribute valule on an entry that does not 
yet exist.

Would you run /usr/lib64/mozldap/ldapsearch   -D "cn=directory 
manager" W -b "cn=cas,cn=ca,dc=ipa,dc=local " -J 
"1.3.6.1.4.1.42.2.27.9.5.2:true:dn:uid=alice,cn=users,cn=accounts,dc=ipa,dc=local" 
"(objectclass=*)"

to get the effective rights under cn=cas,cn=ca,dc=ipa,dc=local

Also you may replay your test case with ACL logs 
(http://www.port389.org/docs/389ds/FAQ/faq.html#Troubleshooting), 
nsslapd-errorlog-level: 262272


thanks
thierry
On 01/13/2017 07:21 AM, Fraser Tweedale wrote:
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 
CA,cn=permissions,cn=
     pbac,dc=ipa,dc=local";)
   ...

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
add?

Thanks,
Fraser



--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code