[Freeipa-devel] [PATCH] sudo and netgroup schema compat updates

[Dmitri Pal]

JR Aquino wrote:
>> I think this is how it is designed right now.
>> The migration to host groups will be slow and painful.
>> I think that approach we planned covers all main use cases and provides
>> enough flexibility for administrators transition from old models and
>> concepts to the new ones.
>> There will be need to the compatibility for older clients for the years
>> to come.
>>     
>
> The design doc seems to disagree:
> http://freeipa.org/page/SUDO_Schema_Design
>
> objectclass: ipaSudoRule
> ...
> memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
> ...
>
> Just to review, so that I can make sure the patch is posted correctly:
>
> The current Sudo Compat Plugin functions as long as:
> An IPASudoRule can consist of:
>
> memberUser: <Single_User|Group>
> memberAllowCmd: <Single_CMD|SudoCmdGroup>
> memberDenyCmd: <Single_CMD|SudoCmdGroup>
> memberHost: <Single_Host|ipaNetGroup> ???
>
> ^ The Schema Design originally suggested that for an ipaSudoRule an
> ipaHostGroup would be used.
>   

http://www.freeipa.org/page/SUDO_Schema_Design#Why_we_must_support_netgroups_in_the_SUDO_rules.3F
Last paragraph of the section. Also see last open question and answer to
it on the page :-)

However... read further...

> This ipaHostGroup would then be duplicated into a ipaNetGroup (Managed
> Entry). 
> This ipaNetGroup would then be translated into an ldap backed nisNetGroup
> (Compat).
>
> I am ok changing the sudorule plugin to point memberHost to an
> ipaNetgroup, however, I think we need to be correct and clear in all the
> previous references.
> There are a LOT of moving parts behind the scenes to make this work
> natively, so the chance for confusion is very high.
>
> What I was suggesting, was that perhaps its not necessary to change the
> sudorule plugin if the eventual end goal is to utilize hostgroups
> natively.  The compat pieces and Managed Entry pieces already handle the
> translation as elegantly as they can given the circumstances.
>
> Is there a negative aspect of having the SudoCompat piece look to an
> ipaHostgroup for its conversion?
>   
I just talked to Nalin and you might be right we can eliminate the need
to support the netgroups in the sudo rule for hosts altogether.
Since each host group will have a corresponding netgroup (until it is
explicitly turned off by admin and it can be turned off only when the
clients do not need netgroups any more which will be many years from
now) the compat plugin can check if there is a corresponding netgroup,
and if there is, use netgroup notation in the generated SUDO rule
instead of expanding the rule to contain the host attributes verbatim.

This looks like a nice and elegant solution but this means that we
*require* the use of the host groups with netgroups. So if the
deployment  has a netgroup that has hosts A,B,C we require the hosts A,B
& C be put into a host group. If admin just creates a new netgroup with
hosts A, B, C in IPA he would not be able to use this netgroup in the
SUDO part at all. May be it is Ok. It will really discourage people from
using the netgroups. If we can require admins to always create a top
level host group for any netgroup they want to have for whatever reason
and this is acceptable then we can avoid allowing direct referencing
netgroups in the rule and thus do not need to add this capability to
SUDO plugin. It will actually save some future work on SSSD too since it
would not need to resolve the netgroups - just host groups.

After some thinking IMO the right approach would be:
1) Adjust the compat plugin as described above
2) Do not add capability to SODO mgmt plugin to point to the netgroup in
the SUDO rule
3) Document the considerations about the netgroups migration
(https://fedorahosted.org/freeipa/ticket/37)   

Thoughts?

> Thanks!
>
> -JR
>
>   


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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