[Freeipa-devel] Where we are with SUDO?

[JR Aquino]

On 11/18/10 3:11 PM, "Dmitri Pal" <dpal at redhat.com> wrote:

>JR Aquino wrote:
>>
>> The IPA SudoRule Structure has largely been based off of what we are
>>doing
>> today with HBAC.
>>
>> HBAC does not distinguish between memberGroup or memberNetgroup... Its
>> simply, memberHost and memberUser for both HBAC and IPASudoRules.
>>
>> Also, when HBAC or IPASudoRules add a member, there is no resulting
>> 'memberOf' or (hbacMemberOf/sudoMemberOf) inserted into the usergroup,
>> hostgroup, command group, etc...  Whereas, if you add a host to a
>> hostgroup, the host ends up with a pointer referring back to the
>> hostgroup.  I believe this was done to provide referential integrity.
>>
>> We will definitely need to modify the schema under the hood if it is
>> necessary to make these shifts, but I am not sure if that sort of change
>> will be effected by the way the backend treats these sorts of objects.
>>
>>   
>
>Nalin is working on a solution to this. We do not need to modify schema.
>Instead he is adding code to make checks on the object type and have a
>way to transform the value in different ways based on this check.

Excellent!

I'll retest as soon as the new patch is available!


>>Sudo, does not support hostgroups, it only knows about nisnetgroups.
>>
>> As such, either we need the backend code to translate this information
>> automatically for us.
>>
>> Or 
>>
>> We need to go down the path of procedurally solving this issue.
>>
>> For example:
>>
>> * Create a user + usergroup
>> * Create a command + commandgroup
>> * Create a host + hostgroup
>> * Create a nisNetgroup with the same name as the ipaHostgroup, and add
>>the
>> hostgroup into the nisNetgroup...
>> * Allow translation to occur and point everything with 1-to-1 except
>>for:
>>  -sudocmdgroups are unknown to sudo, so the individual commands need to
>>be
>> broken out and listed individually in the translation.
>>  -sudoHost will need to point to a (shared name) that represents both an
>> ipaHostgroup and an ipaNisNetgroup.
>>
>> We have discussed this challenge at length, and everyone agrees that
>> nisNetgroups are a thing of the past, that is best forgotten.  However,
>>it
>> is necessary to support them in the interim because sudo currently does
>> not support anything else.  It is an ideal to strive toward getting sudo
>> to support hostgroups, and also to support sssd, but we have a long way
>>to
>> go to get there.
>>
>>
>>   
>I was assuming that this is a procedurally solvable solution during
>migration. In your case when you move to IPA you would need to transfer
>data from the original data source.
>1) All the netgroups that  store the hosts and used in SUDO and other
>places need to be migrated into  IPA back end schema. As you prepare
>data for migration the following reshuffling needs to be done with the
>original data and the resulting LDIF should have:
>    a) all the hosts should be created as host entries
>    b) all hosts should be added to a host group - probably with the
>same name as the name of the netgroup in the original data set
>    c) a netgroup entry with the same name is in the source data set
>should be created pointing to this host group
>    d) memberHost attribute of the SUDO rule should then point to the
>netgroup DN

The Sudo Plugin currently points to the HostGroup DN.  Since we must
solve this issue procedurally by using the same name for the Hostgroup
and nisNetgroup, I would prefer to continue to point to the
HostGroup DN.  This allows for the future of the plugin to remain
sane after sudo natively support sssd/FreeIPA...

I'm concerned that if we force the Sudo Piece to only look at the
nisNetgroup, that it will encourage siloing to occur; the goal is
to facilitate and encourage the usage of hostgroup objects throughout
the framework.

>This solves the issue of migrating data from the old model to the new
>model. Would be nice to have some scripts in the project that would help
>people to take the 2307 + SUDO schema and move to IPA. We do not have
>cycles to do it ourselves and hope that something like this would be
>eventually developed and contributed by the community.
>2) The other question is management of SUDO data on the ongoing basis.
>Until SUDO does not support host groups via a policy plugin the IPA
>admins would have to wrap host groups into netgroups.

Depending on size, this can be daunting...

>A special wrapper
>can be created for the CLI to create a netgroup out of the hostgroup or
>may be it can be a flag to the hostgroup-add to automatically create a
>netgroup with the same name. Something similar to what we do with
>host-add and DNS. 

That sounds VERY promising! I wasn't aware that we had a plugin that could
have triggered adds!

>An alternative is to have a managed entry plugin to
>automatically create a netgroup for every hostgroup in the system. This
>might be even simpler.

I'm not sure how I would go about coding this option...

>I am open to suggestions here but hope that since this is an
>optimization and we are in a bit of ramp up to the release this
>functionality can be contributed soon or can be added later.

I agree.  We are very very close to functional and it makes sense to get
over the hump while bookmarking 'optimizations' that can be revisited
after the major release.

-JR