On 03/31/2014 03:23 PM, Martin Kosek wrote:
On 03/31/2014 01:52 PM, Ludwig Krispenz wrote:
On 03/31/2014 12:32 PM, Martin Kosek wrote:
On 03/31/2014 10:41 AM, Ludwig Krispenz wrote:
In general I think we should implement 1), there will be other scenarios where
it could be useful. If something is needed imemdiately I would also prefer 3)
We need this feature for FreeIPA 4.0, so I am thinking waiting for 389 feature
is not an option unless it'd be done really fast.
how fast does it have to be ? If we just can use the same  concept with
implementation should not take too much time, about a week or so, but we need
to get it accepted by
DS core.
As fast as a light :-) A week should be sufficient, though I am not convinced
that we are able to release that fast or that rushing ACI related
implementation is a good thing to do.
:-) and I am no longer sure if it would be the best way to go since there seem to be may containers you want to apply this and with targetscope=base you would hav eto add the aci to any container you want to control

Question is if we want to go this way (adding ACI for all containers) or the
second way having ACI(s) for all containers in the tree described below.
if you don't see any problems giving access to too many containers I think the combination of your suggestion

(target != "ldap:///cn=etc,SUFFIX";)(targetfilter= ...)
is the best.

The question is, do you want to use an existing attribute,value pair for the 
filter or add something unique to the entries you target. In that case you 
would have to edit the entries and the filter would be enough

Given Petr's findings, I am thinking that solution based on 3) seems like way
to go. We would of course only allow objectclass + cn attributes. I am not
convinced that objectclass like ipaPublicContainer is the right way to go, does
not sound to me as a standard solution and not something that people would
assume they need to do when they are adding a custom container.

When I installed a fresh FreeIPA, I did a (cn=nsContainer) search (results
attached) and there were 61 results. Do we really want to update 61 LDAP
entries and add a custom ipaPublicContainer objectclass to all? Sounds a little
bit hackish to me.

Would adding following ACIs work?

aci: allow anonymous read for "(objectclass=nsContainer)" for cn, objectclass;
except cn=etc,SUFFIX
how do you want to specify the "except" ?
(target != "ldap:///cn=etc,SUFFIX";)

dn: cn=etc,SUFFIX
aci: allow authenticated read for "(objectclass=nsContainer)" for cn,

As I just checked, allowing whole cn=etc,SUFFIX for authenticated only is
something we agreed on during DevConf.

With this approach, the only question is what should we do with nsContainer
based LDAP entries that contains sensitive information. I wonder - is this a
real situation? Are there many nsContainer LDAP entries with sensitive
information? Shouldn't we have a rule instead that would recommend using custom
(not nsContainer) objectclasses to store sensitive information based on cn?
Otherwise it seems to me a an abuse of nsContainer purpose.


Freeipa-devel mailing list

Reply via email to