Re: [Freeipa-devel] New ACIs for cn=etc
On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/23/2014 01:03 PM, Petr Viktorin wrote: On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? We do not have it currently, but AFAIK Honza planned (or even had patches?) to add it in his CA management utility effort. Honza, is that correct? Until this hostgroup is ready (and managed), I think we can have an ACI to allow read access to all authenticated users. OR, we may chose not have an ACI at all given that utilities (ipactl, ipa-replica-manage, ipa-replica-install) operating with cn=masters bind as DM (either via password or with External bind) and i.e. should not need the ACI. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 23.4.2014 13:13, Martin Kosek wrote: On 04/23/2014 01:03 PM, Petr Viktorin wrote: On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? We do not have it currently, but AFAIK Honza planned (or even had patches?) to add it in his CA management utility effort. Honza, is that correct? It would certainly make things prettier. I don't have any patches, but there is a ticket for that: https://fedorahosted.org/freeipa/ticket/3416. Until this hostgroup is ready (and managed), I think we can have an ACI to allow read access to all authenticated users. OR, we may chose not have an ACI at all given that utilities (ipactl, ipa-replica-manage, ipa-replica-install) operating with cn=masters bind as DM (either via password or with External bind) and i.e. should not need the ACI. Renewal scripts need access to cn=masters and bind as host. Martin -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Wed, 2014-04-23 at 13:03 +0200, Petr Viktorin wrote: On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? Yes, we proposed it a few times already. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/23/2014 01:42 PM, Jan Cholasta wrote: On 23.4.2014 13:13, Martin Kosek wrote: On 04/23/2014 01:03 PM, Petr Viktorin wrote: On 04/14/2014 12:55 PM, Martin Kosek wrote: [...] dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) We don't have an ipamasters hostgroup. Should we? We do not have it currently, but AFAIK Honza planned (or even had patches?) to add it in his CA management utility effort. Honza, is that correct? It would certainly make things prettier. I don't have any patches, but there is a ticket for that: https://fedorahosted.org/freeipa/ticket/3416. Sounds like the best way to do this. I've moved the ticket to Needs triage. Until this hostgroup is ready (and managed), I think we can have an ACI to allow read access to all authenticated users. OR, we may chose not have an ACI at all given that utilities (ipactl, ipa-replica-manage, ipa-replica-install) operating with cn=masters bind as DM (either via password or with External bind) and i.e. should not need the ACI. Renewal scripts need access to cn=masters and bind as host. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/16/2014 03:04 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 15:00 +0200, Petr Viktorin wrote: Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? I have no objection to that, but should be last resort if we have no other way IMO, and valid only for objects that are not normally created on a daily basis, as old replicas creating new objects would not know to add the new objectclass. In this case it seem like we should be ok as we do not commonly create these objects, so the chances an old replica creates them are negligible. Simo. Alright. I've reserved 2.16.840.1.113730.3.8.12.23 for a new ipaVirtualOperation objectclass. Let me know if I should use a different one. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. dn: cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) dn: cn=replicas,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading replicas for authenticated users (masters) dn: cn=dna,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading dnaSharedConfig objects for authenticated dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (hosts' certmonger) dn: cn=s4u2proxy,cn=etc,SUFFIX - no ACI needed at this point, KDC access it with DM privileges AFAIK dn: cn=ipaConfig,cn=etc,SUFFIX - ADD aci allowing reading ipaConfigObject attributes for authenticated users. We already plan aci allowing writing them dn: cn=ranges,cn=etc,SUFFIX - ADD aci allowing reading ipaIDrange for authenticated users dn: cn=virtual operations,cn=etc,SUFFIX - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate different host,cn=virtual operations,SUFFIX dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX - no ACI needed dn: cn=Managed Entries,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=automember,cn=etc,SUFFIX - ADD standard automembers ACIs (read, write, delete, ...) dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading cACertificate for anonymous dn: cn=anonymous-limits,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=replication,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (used in ipa-replica-install) dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX - no ACI needed, we already added read aci dn: cn=ad,cn=etc,SUFFIX - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust settings) == That should be pretty much all. I know that devil hides in details, but I did not see any blocker to skip the chance to add proper ACIs also for cn=etc as well and thus remove the all allowing ACI at all (I am afraid that we would be stuck with cn=etc all-allowing ACI for years otherwise). Comments welcome. Agree with the general plan, let's start with this and add permissions as needed. Simo. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: On 04/16/2014 12:50 PM, Petr Viktorin wrote: On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. Right. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? We would need to invent one, like ipaVirtualOperation with one MUST attribute cn and then apply it to all virtual operations and replace nsContainer. It should not be a problem though as we do not provide API to handle the virtual operations. There are very static. Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. Ok. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? Hm, exclusion of this one is probably not needed. User would really only see the containers for Definitions and Templates, not the real configuration (NGP/UGP). dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. Makes sense. Right now, we have 2 types of objects here: 1) system users: simpleSecurityObject objectclass 2) system groups: groupofnames objectclass We can make 2 ACIs, allowing those: - allow reading uid, objectclass of simplesecurityobject to authenticated users - allow reading cn, member, objectclass of groupofnames to authenticated users Yeah we do not need fancy stuff, and we are planning (since forever ?) to give a command to create these entities, so eventually the format will be clear. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On 04/16/2014 02:55 PM, Simo Sorce wrote: On Wed, 2014-04-16 at 13:31 +0200, Martin Kosek wrote: On 04/16/2014 12:50 PM, Petr Viktorin wrote: On 04/14/2014 04:00 PM, Simo Sorce wrote: On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: We can combine this with the general nsContainer read ACI. The problem is that we can only have one target-based exclusion rule. Right. - cn=virtual operations,cn=etc,SUFFIX Could we use a special objectClass rather than nsContainer for these? We would need to invent one, like ipaVirtualOperation with one MUST attribute cn and then apply it to all virtual operations and replace nsContainer. It should not be a problem though as we do not provide API to handle the virtual operations. There are very static. Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? - cn=masters,cn=ipa,cn=etc,SUFFIX This is the one I'd exclude with the target rule. Ok. - cn=Managed Entries,cn=etc,SUFFIX Why exclude this one? Aren't the containers the same in all IPA installs? Hm, exclusion of this one is probably not needed. User would really only see the containers for Definitions and Templates, not the real configuration (NGP/UGP). dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) I'd rather list the attributes and let people add custom attributes themselves. Makes sense. Right now, we have 2 types of objects here: 1) system users: simpleSecurityObject objectclass 2) system groups: groupofnames objectclass We can make 2 ACIs, allowing those: - allow reading uid, objectclass of simplesecurityobject to authenticated users - allow reading cn, member, objectclass of groupofnames to authenticated users Yeah we do not need fancy stuff, and we are planning (since forever ?) to give a command to create these entities, so eventually the format will be clear. Simo. -- Petr³ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Wed, 2014-04-16 at 15:00 +0200, Petr Viktorin wrote: Simo, Rob, would you be OK with changing virtual operation objectclass to our own one to have a better control over it? No, in general I am not ok to change objects that already exist in IPA as it make upgrades with new and old replicas break the old replicas. Also we can add new auxiliray classes but removing structural classes is not possible, you would have to delete and recreate the object, and that would be racy too. I see. How about adding a new objectClass in addition to nsContainer, and using a negative targetfilter? I have no objection to that, but should be last resort if we have no other way IMO, and valid only for objects that are not normally created on a daily basis, as old replicas creating new objects would not know to add the new objectclass. In this case it seem like we should be ok as we do not commonly create these objects, so the chances an old replica creates them are negligible. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] New ACIs for cn=etc
On Mon, 2014-04-14 at 12:55 +0200, Martin Kosek wrote: When heading for a lunch today, I had a discussion with Petr3 about ACIs for cn=etc,SUFFIX. On our initial meeting back at DevConf.cz time, we said we will simply allow all attributes in cn=etc for authenticated users and will just exclude the blacklisted attributes (for context, see ticket #3566). I personally think it is not the best thing to do as it will just move the problem we had with all-allowing ACI one level down from SUFFIX to cn=etc. It would be better to add normal ACIs for cn=etc as well. I searched for nsContainer's in cn=etc and IMO the situation is not so bad, it seems straightforward what ACIs would be needed: == dn: cn=etc,SUFFIX - ADD aci allowing reading nsContainer for anonymous, EXCEPT: - cn=virtual operations,cn=etc,SUFFIX - cn=masters,cn=ipa,cn=etc,SUFFIX - cn=Managed Entries,cn=etc,SUFFIX dn: cn=sysaccounts,cn=etc,SUFFIX - ADD aci allowing reading all attributes but password attributes (people may add unstructured accounts following different objectclasses) dn: cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=masters,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading hosts (to have it separate from global cn=etc one so that we can once assign it only to ipamasters hostgroup for example) dn: cn=replicas,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading replicas for authenticated users (masters) dn: cn=dna,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading dnaSharedConfig objects for authenticated dn: cn=posix-ids,cn=dna,cn=ipa,cn=etc,SUFFIX - no ACI needed dn: cn=ca_renewal,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (hosts' certmonger) dn: cn=s4u2proxy,cn=etc,SUFFIX - no ACI needed at this point, KDC access it with DM privileges AFAIK dn: cn=ipaConfig,cn=etc,SUFFIX - ADD aci allowing reading ipaConfigObject attributes for authenticated users. We already plan aci allowing writing them dn: cn=ranges,cn=etc,SUFFIX - ADD aci allowing reading ipaIDrange for authenticated users dn: cn=virtual operations,cn=etc,SUFFIX - ADD aci allowing reading/updating virtual operations, assign to RBAC privileges dn: cn=retrieve certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=request certificate different host,cn=virtual operations,SUFFIX dn: cn=certificate status,cn=virtual operations,cn=etc,SUFFIX dn: cn=revoke certificate,cn=virtual operations,cn=etc,SUFFIX dn: cn=certificate remove hold,cn=virtual operations,cn=etc,SUFFIX - no ACI needed dn: cn=Managed Entries,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=automember,cn=etc,SUFFIX - ADD standard automembers ACIs (read, write, delete, ...) dn: cn=CAcert,cn=ipa,cn=etc,SUFFIX - ADD aci allowing reading cACertificate for anonymous dn: cn=anonymous-limits,cn=etc,SUFFIX - no ACI needed, not managed by IPA users dn: cn=replication,cn=etc,SUFFIX - ADD aci allowing reading for authenticated users (used in ipa-replica-install) dn: cn=Realm Domains,cn=ipa,cn=etc,SUFFIX - no ACI needed, we already added read aci dn: cn=ad,cn=etc,SUFFIX - ADD aci allowing reading ipaNTDomainAttrs for authenticated users (trust settings) == That should be pretty much all. I know that devil hides in details, but I did not see any blocker to skip the chance to add proper ACIs also for cn=etc as well and thus remove the all allowing ACI at all (I am afraid that we would be stuck with cn=etc all-allowing ACI for years otherwise). Comments welcome. Agree with the general plan, let's start with this and add permissions as needed. Simo. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
