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

[Simo Sorce]

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.