[Freeipa-devel] Read access to container entries

[Ludwig Krispenz]

Hi Petr,

we already discussed on IRC, but see some comments below
On 03/28/2014 04:11 PM, Petr Viktorin wrote:
> Hello,
> I'm trying to add ACIs to allow read access to containers, and I need 
> some input.
>
> The DS's access control system is not designed to allow access to a 
> single entry but not its descendants. The [ACI documentation] suggests 
> some ways to work around it.
>
> This doesn't work that well for read access in IPA:
>
> $SUFFIX needs anonymous read access; ipa-client-install looks for 
> "info=IPA V2.0" anonymously.
> cn=accounts,$SUFFIX needs read access if it or any of its children are 
> to be listed in a GUI
> cn=users,cn=accounts,$SUFFIX needs read access if it or any users are 
> to be listed in a GUI
> uid=*,cn=accounts,$SUFFIX might need to have anonymous reads denied
>
> It's safe to expose IPA's default containers anonymously; all they 
> tell the user is that they're looking an IPA server.
>
> The container entries themselves just have cn and an objectClass of 
> cnContainer, so it's impossible to construct a general targetfilter 
> that targets them but not any possible descendants.
>
> I see 3 possible solutions:
> 1) File a DS RFE to implement [targetscope]. With that we could have 
> ACIs that only target a single entry, so admins could manage read 
> access to containers in the usual way (with permissions).
> 2) Add a (objectClass=nsContainer) filter. The problem here is that if 
> this is on cn=accounts,$S, it would also affect e.g. 
> cn=users,cn=accounts,$S, and other nsContainers under it. For example, 
> cn=$HOSTNAME,cn=masters,cn=ipa,cn=etc,$S is a nsContainer.
> 3) Add a special attribute to mark "public" containers, and add an ACI 
> with a filter on that. Something like objectClass=ipaPublicContainer 
> would do.
there is one more option
4) add an allow aci for cn=accounts,$S and a deny aci for 
cn=*,cn=accounts,$S or uid=*,cn=accounts,$S

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)
>
>
> I'm thinking about 3, but I'd like to ask an LDAP expert for opinions.
>
>
> Note that children can be accessible even if the parent isn't. This 
> whole container business only affects exploring the DIT with a GUI-ish 
> tool.
>