[Freeipa-devel] SUDO community changed SUDO schema!!!

[Dmitri Pal]

On 01/30/2011 11:23 AM, JR Aquino wrote:
> On 1/29/11 3:40 PM, "Dmitri Pal" <dpal at redhat.com> wrote:
>
>> On 01/29/2011 12:37 PM, JR Aquino wrote:
>>> On 1/29/11 9:30 AM, "JR Aquino" <JR.Aquino at citrix.com> wrote:
>>>
>>>> From: Dmitri Pal <dpal at redhat.com<mailto:dpal at redhat.com>>
>>>> Organization: Red Hat
>>>> Reply-To: <dpal at redhat.com<mailto:dpal at redhat.com>>
>>>> Date: Sat, 29 Jan 2011 11:25:17 -0500
>>>> To: <freeipa-devel at redhat.com<mailto:freeipa-devel at redhat.com>>
>>>> Subject: [Freeipa-devel] SUDO community changed SUDO schema!!!
>>>>
>>>>
>>>> sudoNotBefore
>>>>
>>>> A timestamp in the form yyyymmddHHMMZ that indicates start of validity
>>>> of
>>>> this sudoRole. If multiple sudoNotBefore entries are present, the
>>>> earliest is used.
>>>>
>>>> sudoNotAfter
>>>>
>>>> A timestamp in the form yyyymmddHHMMZ that indicates end of validity of
>>>> this sudoRole. If multiple sudoNotAfter entries are present, the last
>>>> one
>>>> is used.
>>>>
>>>> sudoOrder
>>>>
>>>> The sudoRole entries retrieved from the LDAP directory have no inherent
>>>> order. The sudoOrder attribute is an integer (or floating point value
>>>> for
>>>> LDAP servers that support it) that is used to sort the matching
>>>> entries.
>>>> This allows LDAP-based sudoers entries to more closely mimic the
>>>> behaviour of the sudoers file, where the of the entries influences the
>>>> result. If multiple entries match, the entry with the highest sudoOrder
>>>> attribute is chosen. This corresponds to the "last match" behavior of
>>>> the
>>>> sudoers file. If thesudoOrder attribute is not present, a value of 0 is
>>>> assumed.
>>>>
>>>>
>>>> attributetype ( 1.3.6.1.4.1.15953.9.1.8
>>>>    NAME 'sudoNotBefore'
>>>>    DESC 'Start of time interval for which the entry is valid'
>>>>    EQUALITY generalizedTimeMatch
>>>>    ORDERING generalizedTimeOrderingMatch
>>>>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
>>>>
>>>> attributetype ( 1.3.6.1.4.1.15953.9.1.9
>>>>    NAME 'sudoNotAfter'
>>>>    DESC 'End of time interval for which the entry is valid'
>>>>    EQUALITY generalizedTimeMatch
>>>>    ORDERING generalizedTimeOrderingMatch
>>>>    SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
>>>>
>>>> attributeTypes ( 1.3.6.1.4.1.15953.9.1.10
>>>>     NAME 'sudoOrder'
>>>>     DESC 'an integer to order the sudoRole entries'
>>>>     EQUALITY integerMatch
>>>>     ORDERING integerOrderingMatch
>>>>     SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
>>>>
>>>> I have reached out to Todd and the SUDO community to answer these
>>>> questions and concerns Dmitri.
>>>>
>>>> I suspect that we should not have an issue moving forward with the 2.0
>>>> effort, and that we will want to include the feature support in 2.1.
>>>>
>>>> I'll report further once I have more official information from the
>>>> source.
>>>>
>>>> -JR
>>> It is also worth noting:
>>>
>>> These changes are _only_ present in the _developmental_ version of SUDO
>>> and don't yet exist in the current stable version that would be used by
>>> the majority of the community.
>>>
>>> ---===---
>>> http://www.gratisoft.us/sudo/devel.html#1.7.5b2
>>>
>>> ---===---
>>> The current stable version is sudo 1.7.4p6 released on January 19, 2011.
>>> See the download page for a list of binary packages.
>>> The current development version is sudo 1.7.5b2, released on January 21,
>>> 2011.
>>>
>>>
>>>  Major changes between version 1.7.5b1 and 1.7.5b2:
>>>
>>> * LDAP Sudoers entries may now specify a time period for which the entry
>>> is valid. This requires an updated sudoers schema that includes the
>>> sudoNotBefore and sudoNotAfter attributes. Support for timed entries
>>> must
>>> be explicitly enabled in the ldap.conf file. Based on changes from
>>> Andreas
>>> Mueller.
>>> * LDAP Sudoers entries may now specify a sudoOrder attribute that
>>> determines the order in which matching entries are applied; the first
>>> matching entry is used. This requires an updated sudoers schema that
>>> includes the sudOrder attribute. Based on changes from Andreas Mueller.
>>>
>>>
>>> _______________________________________________
>>> Freeipa-devel mailing list
>>> Freeipa-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>>>
>>>
>> I also took a look at the code.
>>
>> Here are some observations based on review of the:
>> http://www.sudo.ws/repos/sudo/file/e52bc15de76d/plugins/sudoers/ldap.c
>> and other parts of the SUDO project
>>
>> 1) There is no community, only one guy
> To be fair, there are patches that I have observed from individuals other
> than Todd.
>
> If I am not mistaken, the original code that brought LDAP support was a
> patch contributed by someone other than Todd.
>
>> 2) He is definitely working on the LDAP I wonder what are the designs
>> and plans
>> 3) The file has bad formatting, I think nobody is reviewing the code
>> that has been submitted during last several months
>> 4) The sorting logic is on the client side (search for qsort). It will
>> check if the order attribute is present. If it is, the value will be
>> used for sorting, otherwise the default value of 0.0 will be used. This
>> means that old ldap servers will be supported by the newer clients.
>> 5) The support of the time range attributes is baked into the ldap
>> filter so only the rules that satisfy the time range are pulled to the
>> client system.
>>
>> So far this implementation does not solve the problem of definitive
>> ordering, only gives the admins some means to do it right if they want
>> (sudoOrder is optional). If some of the rules have order attributes and
>> some do not the result will still be unpredictable. My main concern re
>> 2.0 and 2.1 would be that we would have to create migration script that
>> would populate the sudoOrder attribute with incrementing values once we
>> add it to the schema. This is a "migration" burden day one that I am
>> concerned about. This is why I think about declaring SUDO feature a tech
>> preview so that we can avoid migration burden related to sudoOrder
>> attribute.
>>
>> Thoughts?
> Could you please be more specific to your concerns of migration?  I guess
> I am still confused, since this is a development version, which still has
> several more steps to becoming stable: at least 3 more beta releases,
> followed by release candidates, then finally stable release followed by
> compilation into rpms, deb files and other package systems for various
> distributions.
>
> If we were having this discussion about the current stable release I
> believe I would agree with you, but I feel that it sets a dangerous
> precedent in that there will always be new and experimental features in
> upcoming development releases of software. While it is good to anticipate
> and plan evolution like this, I fear that if we were to stop at each one,
> we would never actually move forward.
>
> As you had indicate, the code automatically assumes a 0.0 value if no data
> is present, same with the time ranges.  SUDO has been around since 1992,
> historically it has never been able to account for 'multiple' rules in
> LDAP with conflicting contents, it has always been a random first match.
> If Todd were to release new code that expects those attributes in LDAP, he
> would risk causing major outages in his install base with lack of backward
> compatibility.
>
> I do not foresee a major migration process at day one.
>
> I would like to also agree with you that his implementation does not
> actually solve the issue of multiple rules and the possibility of the race
> condition.  Instead, I would like to plant the seeds of hope that this
> could be a good sign that Todd would welcome discussions regarding SSSD
> support and collaboration.
>
> -JR
>


The main concern about the solution is the following scenario.
1) IPA releases as is without support of the order attribute.
2) Some time passes and new version of SUDO gets released into some
distros we care about
3) Support for ordered attribute needs to be added to IPA
    Option 1: Allow some entries to have ordered attribute while some
other entries would not. This would allow admin to slowly migrate SUDO
rules from unordered to ordered mode. I see two problems with this:
                    a) If some entries get populated with order
attribute and some do not the clients that have newer version of SUDO
will assume that everything is sorted but the result will be different
from the older clients leading to inconsistency between client
behaviour. This problem can be solved in the SUDO code would have a
config flag to enable and disable sorting but this is outside of our
control.
                    b) We would have to do more work to support this
"optional" attribute.
    Option 2: Treat order attribute as mandatory. This would mean that
all SUDO rules would have to be reloaded and automatically renumbered.
This is less work for us, does not have a problem of unpredictability
but not a pleasant experience for admins.

I do not like Option 1 due to the problems I see with it, I do not like
Option 2 because it will be unpleasant admin experience. So I was thinking:
If we could add the attribute and number it from day one we would not
have to deal with these issues in future. However we do not have time to
do it now, so I was thinking may be we should warn the user community
that the SUDO feature is not fully baked in 2.0 and implement the order
attribute in 2.1 ASAP and then declare that SUDO feature is fully ready.

However while I was writing this it occurred to me that we with IPA are
much less susceptible to the problem of option 1a than other LDAP
servers. The good thing is that we use compat plugin. We can decide to
have a configuration of the compat plugin optionally consider the order
attribute or not. We can have a flag to respect or not the order
attribute when the original internal SUDO entry is processed. If admin
would try to enable the feature and there is at least one SUDO rule that
does not have and order attribute the attempt to enable order attribute
in the compat plugin output would fail. So the more I think about it the
more I see that we can at least avoid problem 1a. This will make me
sleep better ;-)


As for your other comments: I do not see how the feature does not solve
the problem if attribute is actually properly set by admin for all entries.
For integration with SSSD I am all for it. But the other day I was
trying to formulate a compelling reason for such integration. It will
definitely reduce the admin burden for the cases when SUDO and identity
data come from the same server. But what is available right now might
seem sufficient for some time. I think the demand will arise but it is
not there yet. However it would still make sense to talk about it with
SUDO community and engage them in conversation around the idea. 

    



> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


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