openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#7931) Add sudoers schema to OpenLDAP?
by michael＠stroeder.com 08 Sep '14

08 Sep '14

mike(a)flyn.org wrote: > I would like to see the sudoers schema shipped with OpenLDAP: Hmm, I have no clear opinion on this. But adding an app-specific schema files means that it has to be updated each time the app developers changes the schema. Personally I prefer grabbing schema files from the source distribution file of the application. Ciao, Michael.

1 0

Re: (ITS#7932) ldap sign up php web app
by michael＠stroeder.com 08 Sep '14

08 Sep '14

666threesixes666(a)gmail.com wrote: > Full_Name: three sixes > Version: > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.129.13.155) > > > most web applications have the option to use ldap but do not have a clear way of > signing up. > > i suggest a web application that users could drop into registration.domain.com > or auth.domain.com that gives people a way to sign up, request forgotten > passwords, delete accounts, and captcha. Not feasible in a really general way. Ciao, Michael.

1 0

(ITS#7932) ldap sign up php web app
by 666threesixes666＠gmail.com 07 Sep '14

07 Sep '14

Full_Name: three sixes Version: OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.129.13.155) most web applications have the option to use ldap but do not have a clear way of signing up. i suggest a web application that users could drop into registration.domain.com or auth.domain.com that gives people a way to sign up, request forgotten passwords, delete accounts, and captcha. funtoo has part of this.... http://auth.funtoo.org:9093/new such an application would make adoption of ldap much more feasible for me.

1 0

(ITS#7931) Add sudoers schema to OpenLDAP?
by mike＠flyn.org 06 Sep '14

06 Sep '14

Full_Name: W. Michael Petullo Version: 2.4.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.161.95.149) I would like to see the sudoers schema shipped with OpenLDAP: attributetype ( 1.3.6.1.4.1.15953.9.1.1 NAME 'sudoUser' DESC 'User(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.2 NAME 'sudoHost' DESC 'Host(s) who may run sudo' EQUALITY caseExactIA5Match SUBSTR caseExactIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.3 NAME 'sudoCommand' DESC 'Command(s) to be executed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.4 NAME 'sudoRunAs' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.5 NAME 'sudoOption' DESC 'Options(s) followed by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.6 NAME 'sudoRunAsUser' DESC 'User(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) attributetype ( 1.3.6.1.4.1.15953.9.1.7 NAME 'sudoRunAsGroup' DESC 'Group(s) impersonated by sudo' EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 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 ) objectclass ( 1.3.6.1.4.1.15953.9.2.1 NAME 'sudoRole' SUP top STRUCTURAL DESC 'Sudoer Entries' MUST ( cn ) MAY ( sudoUser $ sudoHost $ sudoCommand $ sudoRunAs $ sudoRunAsUser $ sudoRunAsGroup $ sudoOption $ sudoNotBefore $ sudoNotAfter $ sudoOrder $ description ) )

1 0

Re: (ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by varkoly＠suse.com 06 Sep '14

06 Sep '14

Hello, I've tested it from git://git.openldap.org/openldap.git/OPENLDAP_REL_ENG_2_4 with same result. http://www.openldap.org/its/index.cgi/Incoming?id=7239 looks vaguely similar, although with a different overlay. Am Donnerstag, den 04.09.2014, 15:55 +0000 schrieb quanah(a)zimbra.com: > --On Thursday, September 04, 2014 10:11 AM +0000 varkoly(a)suse.com wrote: > > > Full_Name: Peter Varkoly > > Version: 2.4.26, 2.4.39 > > Hello, > > Can you please test using the current RE24 code? There have been > significant updates made to the overlay interactions since 2.4.39. > > Thanks! > > --Quanah > > > -- > > Quanah Gibson-Mount > Server Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- Peter Varkoly Sr. Developer SUSE Linux Enterprise Applications SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany

1 0

(ITS#7930) slapo-chain causes double-free with rwm
by hyc＠openldap.org 06 Sep '14

06 Sep '14

Full_Name: Howard Chu Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc chaining substitutes op->o_req_dn and then restores its original value after performing the chained op. But rwm tries to cleanup op->o_req_dn when the chained op finishes, and so the original DN will be invalid after that. Partial fix: chain should only resto t the original value if the current value matches the last value that chain used. Additional fix: rwm should not cleanup at this time, because the send_ldap_result() of the chained op is not necessarily the final result of the original op. (E.g., in a search that processes multiple search refs, send_ldap_result will occur for each ref that is chained.)

1 0

Re: (ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by quanah＠zimbra.com 04 Sep '14

04 Sep '14

--On Thursday, September 04, 2014 10:11 AM +0000 varkoly(a)suse.com wrote: > Full_Name: Peter Varkoly > Version: 2.4.26, 2.4.39 Hello, Can you please test using the current RE24 code? There have been significant updates made to the overlay interactions since 2.4.39. Thanks! --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7929) memberof overlay supresses accesslog olcAccessLogOps = all
by varkoly＠suse.com 04 Sep '14

04 Sep '14

Full_Name: Peter Varkoly Version: 2.4.26, 2.4.39 OS: SUSE Enterprise Server URL: ftp://ftp.suse.com/pub/people/varkoly Submission from: (NULL) (2620:113:80c0:5::2222) Enabling both the "memberof" and "accesslog" overlays in openldap causes accesslog to only log "reads" and "session" operations when logops is set to all (olcAccessLogOps = all). Disabling the "memberof" overlay results in "writes", "reads" and "session" operations to be logged. Setting "olcAccessLogOps = writes" in conjunction with the "memberof" overlay results in "writes" operations to be logged. Expected result is that when "olcAccessLogOps = all" is set for the "accesslog" overlay together with the "memberof" overlay, that all operations (add, modify, delete, modrdn, search, bind, unbind, abandon, compare) are logged to cn=accesslog. The order of activating the overlays is irrelevant. We have tested it by activating first memberof and accesslog too. We are using the config-backend. The configuration will be available soon under the provided URL.

1 0

Re: (ITS#7928) Segfault when cancelling syncprov search
by hyc＠symas.com 28 Aug '14

28 Aug '14

ben(a)morrow.me.uk wrote: > Full_Name: Ben Morrow > Version: 2.4.39 and git head > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (86.140.232.115) > > > I believe I have found a crashing bug in the syncprov overlay. If I > start a refreshAndPersist search, wait for the persist phase to start > and at least one change to be returned, and then cancel the search, > slapd dies with SIGSEGV. (I don't know how many of these conditions are > necessary. I suspect that cancelling any syncprov search will cause the > same crash, but I haven't investigated that.) > > I also believe the following change to > servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: > > slap_callback *sc = op->o_callback; > op->o_callback = sc->sc_next; > - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); > + syncprov_drop_psearch( sc->sc_private, 0 ); > > The crash I see actually occurs in libthr (FreeBSD's threading library), > because drop_psearch passes its first argument to free_syncop which > starts by trying to lock a mutex; but in fact the object being passed is > not the right type at all, and where there is supposed to be a mutex > there is instead a function pointer. Thanks, looks like you're right. Fixed in git master. > > Ben > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7928) Segfault when cancelling syncprov search
by ben＠morrow.me.uk 28 Aug '14

28 Aug '14

Full_Name: Ben Morrow Version: 2.4.39 and git head OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.140.232.115) I believe I have found a crashing bug in the syncprov overlay. If I start a refreshAndPersist search, wait for the persist phase to start and at least one change to be returned, and then cancel the search, slapd dies with SIGSEGV. (I don't know how many of these conditions are necessary. I suspect that cancelling any syncprov search will cause the same crash, but I haven't investigated that.) I also believe the following change to servers/slapd/overlays/syncprov.c:syncprov_ab_cleanup fixes the prlelem: slap_callback *sc = op->o_callback; op->o_callback = sc->sc_next; - syncprov_drop_psearch( op->o_callback->sc_private, 0 ); + syncprov_drop_psearch( sc->sc_private, 0 ); The crash I see actually occurs in libthr (FreeBSD's threading library), because drop_psearch passes its first argument to free_syncop which starts by trying to lock a mutex; but in fact the object being passed is not the right type at all, and where there is supposed to be a mutex there is instead a function pointer. Ben

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs