Simo Sorce wrote:
> On Fri, 15 Oct 2010 11:36:50 -0400
> Dmitri Pal <> wrote:
>> Hello,
>> Currently HBAC login group is defined as:
>> objectClasses: (2.16.840.1.113730. NAME 'ipaHBACServiceGroup'
>> DESC 'IPA HBAC service group object class' SUP nestedGroup STRUCTURAL
>> X-ORIGIN 'IPA v2' )
>> Which means it can be nested.
>> In the recent discussion about SUDO and groups of SUDO commands we
>> settled down on the
>> objectClasses: (2.16.840.1.113730. NAME 'ipaSudoCmdGrp' DESC
>> 'IPA object class to store groups of SUDO commands' SUP groupOfNames
>> MUST ( ipaUniqueID ) STRUCTURAL X-ORIGIN 'IPA v2' )
>> Which we decided should not support nesting.
>> Looking at the UI for the HBAC and complexity of the manipulation with
>> the HBAC object and related hbac services and groups of those it
>> occurred to me that one of the simplifications that we can have is
>> disallowing nesting of the HBAC login groups. It is expected that
>> there will be not many of those anyways. If we need it later we will
>> change it to support nesting. However the nesting is already
>> implemented in CLI and actually works. I tried and everything is
>> documented and seems ok.
>> But group nesting in UI is a bit of nightmare. It is unclear whether
>> the nesting is actually a use case that we need to support here.
>> Thoughts?
> Unless there is a good reason to prevent nesting then I don't think
> it makes sense to undo what has already been done.
> If complexity is perceived as problematic than what we can do is
> provide guidelines on how/when it is or not appropriate to use nesting.
> Simo.
The dilemma here is:
* Undo schema and CLI to simplify UI
Pros: less work in UI
Cons: reduces functionality and undoes what is already done (affects
help and CLI)
* Implement UI to handle nesting and do not touch schema and CLI
Pros: Does not undo anything and does not reduce functionality that
someone might want at some point
Con: Much more work in UI
* Leave CLI and schema as is but in UI not support nesting
Pros: Medium amount of work
Cons: Ugly

I do not know what is the best approach here.
IMO first option is less risky and less work.

Thank you,
Dmitri Pal

Engineering Manager IPA project,
Red Hat Inc.

Looking to carve out IT costs?

Freeipa-devel mailing list

Reply via email to