On Wed, 02 Dec 2015, Simo Sorce wrote:
>>>> We also have to fix the permission to change keytab, so that it uses
>>>> the new
>>>> style (https://fedorahosted.org/freeipa/ticket/5487). I would
>>>> actually make
>>>> this ticket and the ipa-sam ticket a blocker for this patch set.
>>>>
>>>> Otherwise you are actually introducing a switch that breaks FreeIPA
>>>> as some of
>>>> it's core server functions still use the old method.
>>>
>>> The point of this patchset is to introduce the switch early so that
>>> current server will support the off switch when newer servers down the
>>> road are ready to flip it. The defaults are still to allow these
>>> operations for services/hosts.
>>
>> I still do not get the logic about an early switch. Now, if switch is
>> turned
>> on, FreeIPA server breaks on several places. I would really rather
>> expect the
>> switch to be introduced when the server itself supports it. Then,
>> admin would
>> enable it when the clients are sufficiently updated and can use the
>> new method.
>>
>> Why would admin want to enable the switch early if it breaks FreeIPA
>> some of
>> the FreeIPA servers? Permission can be upgraded in newer version and get
>> replicated, that's fine. But ipa-sam would be still broken on this old
>> FreeIPA
>> server.
> Old server is not a problem here: ipa-sam only talks to the
> localhost-based server as we always use ldapi protocol. So if server is
> running old-behavior FreeIPA, ipa-sam on the same server will work
> against it.
>
> What I don't want to have is a situation where setkeytab is disabled and
> a new server obeys it but ipa-sam on this new server is not updated and
> will expectedly fail. We are not that forced to do the change right now
> in 4.3, given that the default will still be to keep setkeytab, thus we
> can wait with this patch until ipa-sam is fixed and then push both
> patches into the closest release, be it 4.3.x (x>=0) or whatever is the
> next one.
>

+1, fixing ipa-sam would be then a release blocker for 4.3 which is not
desired.

Also what about adding support for "ipaProtectedoperation check" for
user principals?

I'm afraid that forbidding getting user principal might be regarded as a
regression which might cause that admins won't set DisableSetKeytab.

One thing at a time.
We have bugs open for all these things, but I see no reason not to add
an *optional* setting just because some things break when it is turned
on.
The problem is that current getkeytab extended operation has not enough
information to be a replacement for ipa-sam's use of setkeytab, as I've
found with your current patches. So adding an optional setting in the
hope that it will not be used in real life is a bit naive, but if people
activate it, whole trust setup will break. I still prefer to have the
patchset first be completed and then merged. There is no problem in
keeping it aside while functionality is being implemented, we can
trivially rebase.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to