Re: [Freeipa-devel] [PATCH] Fixed permission lookup
Rob Crittenden wrote: > Jan Zelený wrote: > > Martin Kosek wrote: > >> On Fri, 2011-01-28 at 09:21 +0100, Martin Kosek wrote: > >>> On Thu, 2011-01-27 at 15:41 +0100, Jan Zelený wrote: > Rob Crittenden wrote: > > Jan Zelený wrote: > >> Martin Kosek wrote: > >>> On Thu, 2011-01-27 at 11:15 +0100, Jan Zelený wrote: > Lookup based on --filter wasn't implemented at all. It did't show > until now, because of bug sitting on top of it which was > resulting in internal error. This patch fixes the bug and adds > the filtering functionality. > > https://fedorahosted.org/freeipa/ticket/818 > >>> > >>> NACK > >>> > >>> Did you build this patch on current master? Because in your patch, > >>> you removed changes in permission-find from my previous patch > >>> "017 ACI plugin supports prefixes". After your patch, > >>> permission-find fails: > >>> > >>> $ ipa permission-find > >>> ipa: ERROR: 'aciprefix' is required > >>> > >>> Martin > >> > >> Sorry, I accidentaly mixed the code with a part of the older one. > >> Sending corrected patch. > >> > >> Jan > > > > I think the more stuff in baseldap.py:LDAPSearch() was there because > > adding entries in a post_callback wasn't working. It only let you > > reduce the number or modify what was already there IIRC. > > > > From what I know, lists should allow you to expand them without any > > > > problems > > (not sure how is the concept called in Python, Pavel told me about > it). Also I didn't encounter any problems with this approach (and the > post callback actually adds some entries), that's why I changed it > the way I did. > > Jan > >>> > >>> ACK > >>> > >>> I think the concept of adding new items to list 'entries' is right. > >>> > >>> Martin > >> > >> Second-thought-NACK > >> > >> After some thoughts about permissions and ACIs I think the ACI filtering > >> should be moved to ACI plugin - aci_find command. So that it is > >> available to other commands built over ACI plugin that would need > >> searching by filter. > >> > >> A good place to move the filtering by 'filter' would be instead of the > >> following comment in aci.py: > >> > >> # TODO: searching by: filter, subtree > >> > >> Martin > > > > Good catch. I'm sending another version of the patch in attachment. > > > > Jan > > This only does filter exact matches, is that adequate or should we > return any filter that has the query as a substring? > > rob I thought about that as well. If you think it is more appropriate, I'll update the patch. But IMO this behavior is what users will expect. Jan ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] SUDO community changed SUDO schema!!!
On 01/30/2011 11:23 AM, JR Aquino wrote: > On 1/29/11 3:40 PM, "Dmitri Pal" wrote: > >> On 01/29/2011 12:37 PM, JR Aquino wrote: >>> On 1/29/11 9:30 AM, "JR Aquino" wrote: >>> From: Dmitri Pal mailto:d...@redhat.com>> Organization: Red Hat Reply-To: mailto:d...@redhat.com>> Date: Sat, 29 Jan 2011 11:25:17 -0500 To: mailto:freeipa-devel@redhat.com>> Subject: [Freeipa-devel] SUDO community changed SUDO schema!!! sudoNotBefore A timestamp in the form mmddHHMMZ that indicates start of validity of this sudoRole. If multiple sudoNotBefore entries are present, the earliest is used. sudoNotAfter A timestamp in the form mmddHHMMZ 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@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 use
Re: [Freeipa-devel] [PATCH] Fixed IPA.widget's load, save, and is_dirty.
On 01/30/2011 12:13 AM, Endi Sukma Dewata wrote: This patch fixes the problem leaving the user details page. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel ACK. Pushed to master ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] SUDO community changed SUDO schema!!!
On 1/29/11 3:40 PM, "Dmitri Pal" wrote: >On 01/29/2011 12:37 PM, JR Aquino wrote: >> On 1/29/11 9:30 AM, "JR Aquino" wrote: >> >>> From: Dmitri Pal mailto:d...@redhat.com>> >>> Organization: Red Hat >>> Reply-To: mailto:d...@redhat.com>> >>> Date: Sat, 29 Jan 2011 11:25:17 -0500 >>> To: mailto:freeipa-devel@redhat.com>> >>> Subject: [Freeipa-devel] SUDO community changed SUDO schema!!! >>> >>> >>> sudoNotBefore >>> >>> A timestamp in the form mmddHHMMZ that indicates start of validity >>>of >>> this sudoRole. If multiple sudoNotBefore entries are present, the >>> earliest is used. >>> >>> sudoNotAfter >>> >>> A timestamp in the form mmddHHMMZ 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@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 ra
