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

[Rob Crittenden]

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