Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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? -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
On Wed, 2014-04-16 at 10:02 +0200, 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@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@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? Creatorsname is inflexible as you cannot change it, we should probably have a way to add a role/group attribute at add time that would bind the object to specific roles/groups of users, but beyond this details it looks pretty powerful. One issue is how you still limit access to some attributes that you may not want to allow the creator to set or change, for example ipaUniqueId or similar things, that should always be under control of the system. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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 ? ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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). Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] #4054 - ACIs for managing own hosts, users, groups...
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@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@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. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
