Re: [Freeipa-devel] GetEffectiveRights and add ACIs
On Mon, 2017-01-16 at 17:09 +0100, Ludwig Krispenz wrote: > On 01/13/2017 06:24 PM, thierry bordaz wrote: > > 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 > I think we need a 389-ds ticket as well. Looking into it, the aci code > contains parts to construct a template entry to evaluate access to a non > existent entry, but it is not called because either entries are found > and processed or the search returns no such object. > It should be possible to make this work. Agreed, lets make a ds ticket for this. It sounds like Fraser is blocked on this, so we should probably work it out sooner than later, but I think that can be discussed at triage. -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part -- 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
Re: [Freeipa-devel] GetEffectiveRights and add ACIs
On 01/13/2017 06:24 PM, thierry bordaz wrote: 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 I think we need a 389-ds ticket as well. Looking into it, the aci code contains parts to construct a template entry to evaluate access to a non existent entry, but it is not called because either entries are found and processed or the search returns no such object. It should be possible to make this work. 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 -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 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
Re: [Freeipa-devel] GetEffectiveRights and add ACIs
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
Re: [Freeipa-devel] GetEffectiveRights and add ACIs
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 -- Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 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
Re: [Freeipa-devel] GetEffectiveRights and add ACIs
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
[Freeipa-devel] GetEffectiveRights and add ACIs
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