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

[Martin Kosek]

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