[Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...

[Petr Viktorin]

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.com at 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.com at 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.

-- 
Petr³