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

[Simo Sorce]

On Wed, 2014-04-16 at 13:12 +0200, Martin Kosek wrote:
> On 04/16/2014 10:35 AM, Jan Cholasta wrote:
> > On 16.4.2014 10:20, 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?
> >>
> >>
> > 
> > I don't think we need creatorsName, we already have managedBy. Or am I missing
> > something?
> > 
> > Honza
> 
> Currently, managedBy is our own attribute where we can put DNs of other host
> entries that can manage/edit the host. So you are right, you could partially
> solve this use case with managedBy.
> 
> User adding a new host would, however, need to pre-fill managedBy with own DN
> so that it is acknowledged as host "manager". On the other side, creatorsName
> is an LDAP operational attribute filled automatically. So IMO it would fit the
> use case described in the ticket better.
> 
> But as you see, there are different approaches to do that, which confirms my
> intent to only provide API for creating this type of permissions and let user
> create it himself.

Agreed.

Simo.