[Freeipa-devel] [RFE] Remove source hosts from HBAC

[Rob Crittenden]

Dmitri Pal wrote:
> On 04/08/2013 09:37 AM, Rob Crittenden wrote:
>> Petr Vobornik wrote:
>>> On 04/08/2013 03:03 PM, Rob Crittenden wrote:
>>>> Petr Vobornik wrote:
>>>>> On 04/05/2013 07:59 PM, Ana Krivokapic wrote:
>>>>>> Hello list,
>>>>>>
>>>>>> I have been thinking about the possible implementation for a
>>>>>> solution of
>>>>>> ticket https://fedorahosted.org/freeipa/ticket/3528. There are
>>>>>> several
>>>>>> options:
>>>>>>
>>>>>> 1. Completely remove the commands and command options related to
>>>>>> source
>>>>>> hosts in HBAC. This might not be a good idea as it could cause
>>>>>> problems
>>>>>> for older clients.
>>>>>>
>>>>>> 2. Hide these commands/options from the web UI, but leave them in
>>>>>> CLI.
>>>>>> This would keep the API intact, but I don't like the idea of
>>>>>> introducing
>>>>>> inconsistencies between CLI and web UI.
>>>>>>
>>>>>> 3. Do not remove anything, but issue deprecation warnings. The user
>>>>>> will
>>>>>> see a warning when using these commands/options, but everything will
>>>>>> still work.
>>>>>>
>>>>>> 4. Do not remove anything, but raise exceptions. This would
>>>>>> effectively
>>>>>> prevent the user from using these commands/options, as the exception
>>>>>> will break the execution of a command.
>>>>>>
>>>>>> In any case, any reference to source hosts should be removed from
>>>>>> help
>>>>>> and documentation.
>>>>>>
>>>>>> I am leaning towards options 3 or 4.
>>>>>>
>>>>>> Thoughts, comments and ideas are welcome.
>>>>>>
>>>>>
>>>>> IMHO the main question is whether we want to deprecate it or remove
>>>>> it.
>>>>> SSSD is deprecating it so I would go that way too.
>>>>>
>>>>> #1 and #4 are basically a removal, #4 a bad one.
>>>>> #2 is removal from Web UI perspective.
>>>>>
>>>>> I would do #3 with some changes. In both Web UI and CLI there
>>>>> should be
>>>>> clear label that the section/options are deprecated. We may
>>>>> introduce a
>>>>> deprecated flag. With this change we don't have to show the
>>>>> warning. But
>>>>> in CLI we might because user didn't had to read help beforehand.
>>>>
>>>> It has been deprecated for quite a while now. This was raised
>>>> because we
>>>> let users enter this data via the UI and CLI and it does absolutely
>>>> nothing which is terribly misleading.
>>>>
>>>> I think that it should be removed from the UI completely. I'm torn with
>>>> the CLI, though leaning on hiding the options.
>>>
>>> Removing it from UI and hiding it in CLI might work for users. I assume
>>> that it will break scripts which are using CLI ('error: no such
>>> option:'). API based scripts will continue to work.
>>>
>>> Do we want to break CLI-based scripts and keep compatibility with
>>> API-based ones?
>>>
>>>>
>>>> It might be worthwhile to also raise an exception if anyone tries to
>>>> use
>>>> it via a script or otherwise.
>>>
>>> Wouldn't removing the options raise an exception as well? I don't see a
>>> point in keeping them when it will always raise an exception.
>>
>> You seem to be following my line of reasoning: if we remove the
>> options it is going to break CLI-based scripts. If we don't remove
>> them then we need to raise an exception.
>>
>> Or we do some odd combination of both, depending on what our goal is.
>>
>> I would normally argue against removing a command-line option but
>> given that these literally don't do anything now, I'm actually leaning
>> towards removing them.
>>
>> For those using the API directly then yeah, we probably want to raise
>> an exception to be absolutely clear, "don't do it."
>>
>> rob
>>
>> _______________________________________________
>> Freeipa-devel mailing list
>> Freeipa-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
> Can we just ignore the option and warn if we encounter it?
> What is the harm of ignoring is it already does not do anything?
> But it also would not break anyone.
> Would that be better?
>

We basically ignore it now. The downside is it leaves the impression 
that you are limiting the rule by source host, which it isn't.

rob