On 04/29/2014 02:48 PM, Simo Sorce wrote:
> 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
>>> 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, 
>>> We discussed this on a meeting and it was mentioned that we can just start
>>> 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  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
>>> 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
>> 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
>> by default
>> and educate users how they can change it if it does not fit their needs. IMO
>> may be more transparent and deterministic than to come with some hard coded
>> changes in ipa-server-install that will create different defaults after
>> 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.
User plugin is just one part of the change we do in access control. What about
config object, hosts, host groups, ID ranges, netgroups, permissions, etc.?
These are now accessible for authenticated users only and not for the
anonymous. Should we then make them anonymous on upgrades as well?
Then I doubt anyone would change it after upgrade to be more restricted
default. I thought we created the new default to be the access control we
recommend for most servers and which we expect to be present at most
deployments. I.e. both on upgrades and new installations.
Freeipa-devel mailing list