On Tue, 2014-04-29 at 14:21 +0200, Martin Kosek wrote: > 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) > > call. > > 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.
It will break working servers pretty badly, that's a big NO on my side. You do not want people to scramble understanding a new ACI system at gunpoint because their production environment is broken. It is a little harder for us, true, but it is worth it. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
