[Freeipa-devel] Where we are with SUDO?

[Dmitri Pal]

JR Aquino wrote:
> On 11/18/10 8:16 AM, "Nalin Dahyabhai" <nalin at redhat.com> wrote:
>   
>> <snipit>
>>     
>>> ToDo's:
>>>
>>> * Get sudo compat to translate usergroup/posix group's such that it can
>>> prepend a %groupname <- notice that it is not fully qualified dn.
>>>       
>> If memberUser can point to either a user or a group, and we read a
>> memberUser entry's "cn" attribute, we don't currently have a way to
>> avoid throwing the "cn" values from user entries into the mix.  I
>> could've sworn we were using memberGroup and memberNetgroup for those
>> cases to avoid this, but it appears I was mistaken.
>>     
>
> 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.


>>> * Get sudo compat to translate the 'hostgroups' into whatever their
>>> respective nisnetgroups should be and refer to them as +nisnetgroupname
>>> <-
>>> again, can't be fully qualified in the translation.
>>>       
>> That won't work -- a hostgroup isn't a netgroup, so the name of a
>> hostgroup won't mean anything to a client if we provide it there.
>>     
>
> From the start of this project, we have faced this challenge, and need to
> have an answer for it.
>
> 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
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. 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. 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 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.

Thank you,
Dmitri

> -JR
>
>   


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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