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

[Dmitri Pal]

On 04/08/2013 01:30 PM, Rob Crittenden wrote:
> 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

IMO if we add a warning when you try to add, modify or view it
(everything other than remove it) we would give admin enough hints
without breaking his scripts.


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/