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

[Simo Sorce]

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 ?