On 04/16/2014 03:42 PM, Simo Sorce wrote: > On Wed, 2014-04-16 at 14:55 +0200, Martin Kosek wrote: >> On 04/16/2014 02:49 PM, Petr Viktorin wrote: >>> On 04/16/2014 02:45 PM, Simo Sorce wrote: >>>> On Wed, 2014-04-16 at 10:20 +0200, Petr Viktorin wrote: >>>>> On 04/16/2014 10:02 AM, Martin Kosek wrote: >>>>>> I was looking into ticket >>>>>> https://fedorahosted.org/freeipa/ticket/4054 >>>>>> and experimenting with ACIs allowing privileged users to manage only >>>>>> their own LDAP objects. >>>>>> >>>>>> As already proposed in the Bugzilla, I had success with following ACIs: >>>>>> >>>>>> ~~~~~~~~~~~~~~~~ >>>>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>>>> add: aci >>>>>> aci: (targetattr = "userclass")(targetfilter = >>>>>> "(objectclass=ipahost)")(version 3.0;acl "permission:Modify own >>>>>> hosts";allow (write) userattr = "creatorsName#USERDN";) >>>>>> >>>>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>>>> >>>>>> # ldapmodify -h `hostname` -D "cn=Directory Manager" -x -w Secret123 >>>>>> dn: cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test >>>>>> add: aci >>>>>> aci: (targetfilter = "(objectclass=ipahost)")(version 3.0;acl >>>>>> "permission:Modify own hosts";allow (delete) userattr = >>>>>> "creatorsName#USERDN";) >>>>>> >>>>>> modifying entry "cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test" >>>>>> ~~~~~~~~~~~~~~~~ >>>>>> >>>>>> When I then added a user fbar with permission "Add hosts", I was able to >>>>>> do exactly what proposed in the ticket: >>>>>> >>>>>> >>>>>> $ ipa host-add test.example.com --force >>>>>> ----------------------------- >>>>>> Added host "test.example.com" >>>>>> ----------------------------- >>>>>> Host name: test.example.com >>>>>> Principal name: host/test.example....@mkosek-fedora20.test >>>>>> Password: False >>>>>> Keytab: False >>>>>> Managed by: test.example.com >>>>>> >>>>>> $ ipa host-mod test.example.com --class foo >>>>>> -------------------------------- >>>>>> Modified host "test.example.com" >>>>>> -------------------------------- >>>>>> Host name: test.example.com >>>>>> Principal name: host/test.example....@mkosek-fedora20.test >>>>>> Class: foo >>>>>> Password: False >>>>>> Keytab: False >>>>>> Managed by: test.example.com >>>>>> >>>>>> $ ipa host-mod admin.example.com --class foo >>>>>> ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the >>>>>> 'userClass' attribute of entry >>>>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>>>> >>>>>> >>>>>> $ ipa host-del admin.example.com >>>>>> ipa: ERROR: Insufficient access: Insufficient 'delete' privilege to >>>>>> delete the entry >>>>>> 'fqdn=admin.example.com,cn=computers,cn=accounts,dc=mkosek-fedora20,dc=test'. >>>>>> >>>>>> >>>>>> $ ipa host-del test.example.com >>>>>> ------------------------------- >>>>>> Deleted host "test.example.com" >>>>>> ------------------------------- >>>>>> >>>>>> I think this could be pretty powerful also with other LDAP objects. >>>>>> Question is what can be done to allow that to our users. >>>>>> >>>>>> I do not think we should add these ACIs by default as not everybody >>>>>> would like them. But if we enhance our permission API to allow the >>>>>> userattr bind rule, admins could add these ACIs at their wish. >>>>>> >>>>>> IMO the API is not that difficult, something like this could work: >>>>>> >>>>>> $ ipa permission-add test --bindtype=userattr --bind-attr=creatorsname >>>>>> --bind-attr-type=USERDN >>>>>> >>>>>> --bind-attr could be more or less free form text to allow "creatorsname" >>>>>> or "parent[0].creatorsname" >>>>>> --bind-attr-type would be enum of values USERDN/GROUPDN >>>>>> >>>>>> This should cover most of the basic use cases. >>>>>> >>>>>> Thoughts? >>>>>> >>>>> >>>>> Makes sense. I'd do it around the time we move self-service to >>>>> permissions. >>>>> >>>>> Simo, can you reserve two more OIDs for the attributes? >>>> >>>> What attributes ? userclass ? Can't we simply use a group/role ? >>> >>> The --bind-attr and --bind-attr-type values will need to be stored in the >>> permission entry, so we'll need ipaPermBindAttr and ipaPermBindAttrType. >> >> I would personally wait with reserving OID until we create a design of this >> feature as there are several approaches. We could for example need one more >> attribute, ipaPermBindAttrDepth we would use for control of the ACI effective >> depth (mutli valued, values 0-4). > > Agreed, there is no hurry until we have a design page. > > simo.
I personally had a secret wish we could make this RFE happen in 4.0, but it is too late for that - thus moving the ticket to 4.1. Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel