[Freeipa-devel] Draft: Read permissions for user

Martin Kosek mkosek at redhat.com
Tue Apr 29 12:21:55 UTC 2014

On 04/29/2014 01:03 PM, Petr Viktorin wrote:
> On 04/24/2014 11:35 AM, Martin Kosek wrote:
>> On 04/23/2014 10:53 PM, Martin Kosek wrote:
>>> On 04/23/2014 08:07 PM, Simo Sorce wrote:
> [...]
>>>> I know, we may need to provide another permission admins can use to turn
>>>> on anonymous searches for those attributes too.
>>>> We may also decide that on upgrade vs new install we retain anonymous
>>>> access.
>>>> Simo.
> This is an interesting challenge.
> We want the permission to be set to anonymous when:
> 1) we're creating it, and
> 2) the updater is *not* run from ipa-server-install (which would mean we're
> installing a new cluster).
> Full analysis below, [0]
> We discussed this on a meeting and it was mentioned that we can just start with
> anonymous, and simply change to "all authenticated" at the end of
> ipa-server-install. Thinking about it, I don't like that approach.
> We may want an ACI audit tool [1] to list differences from defaults.
> For uses like this, the metadata should list to up-to-date "best practices",
> i.e. what you'd get with a fresh ipa-server-install.
> So the metadata should list the bind type as all authenticated, and setting it
> to anonymous should be handled as a special operation.
> This will be somewhat harder to code but I think it's worth it.

I agree with Petr - managed permission definition should state our recommended
and default access control that we are convinced that will fit most
deployments. Restrictive or benevolent admins can always change the default
with simple

$ ipa permission-mod --bindtype=(all|anonymous|permission)


Maybe the easiest way after all will be to list the changes in access control
in the release note, compared to FreeIPA 3.x, e.g.

1) Host groups read access change from anonymous to authenticated by default
2) User calendar attributes read access change from anonymous to authenticated
by default

and educate users how they can change it if it does not fit their needs. IMO it
may be more transparent and deterministic than to come with some hard coded
changes in ipa-server-install that will create different defaults after upgrade
and new installation.


More information about the Freeipa-devel mailing list