[Freeipa-devel] [PATCH 556-557] Add option to disable setkeytab extended operations

[Simo Sorce]

On Thu, 2015-12-03 at 12:21 +0200, Alexander Bokovoy wrote:
> 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.

I just sent patches 562 and 563 which will address the ipa-sam issue
(tested by Alexander already).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York