openldap-bugs October 2007

openldap-bugs@openldap.org

38 participants
215 discussions

Re: ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Yes, it looks like we're using an invalid format for the issuer component. >> Seems like using the GSER format is a bit harder to parse, since we have no >> reliable indicator of where the rdnSequence ends. Any thoughts? > > In general, I agree. In this specific case, it ends at the end of the > octetString :) I take that back. Section 3.20 of RFC3641 says >>> 3.20. Variant Encodings The values of some named complex ASN.1 types have special string encodings. These special encodings are always used instead of the encoding that would otherwise apply based on the ASN.1 type definition. VariantEncoding = RDNSequenceValue / RelativeDistinguishedNameValue / ORAddressValue A value of the RDNSequence type, i.e., a distinguished name, is encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN character string. The character string is first derived according to the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then encoded as if it were a UTF8String value, i.e., between double quotes with any embedded double quotes escaped by being repeated. <<< I.e., the sequence should be enclosed in double quotes. So your example should be { serialNumber 3, issuer rdnSequence:"email=ca(a)example.com,cn=example ca,o=example,st=xx, c=us" } -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: ITS#5072 incorrect certificateExactAssertion()
by ando＠sys-net.it 05 Oct '07

05 Oct '07

hyc(a)symas.com wrote: > Yes, it looks like we're using an invalid format for the issuer component. > Seems like using the GSER format is a bit harder to parse, since we have no > reliable indicator of where the rdnSequence ends. Any thoughts? In general, I agree. In this specific case, it ends at the end of the octetString :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

ITS#5072 incorrect certificateExactAssertion()
by hyc＠symas.com 05 Oct '07

05 Oct '07

Yes, it looks like we're using an invalid format for the issuer component. Seems like using the GSER format is a bit harder to parse, since we have no reliable indicator of where the rdnSequence ends. Any thoughts? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5168) slapo-rwm(5) does not handle UUID syntax attrs in seach filters
by ando＠sys-net.it 04 Oct '07

04 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando I found out that most of the issues I was seeing with syncrepl were a (nasty) side-effect of the fact that slapo-rwm does not play well with UUID-syntax attrs in search filters; unfortunately, syncrepl heavily exploits searching with equality filters on entryUUID... fixed. PS: sorry for the noise.

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 04 Oct '07

04 Oct '07

Well, well. Forgive me for saying that now you're beeing a little narrow minded. If programs that belong to software like openldap (such as slapadd) do 'setuid()' themselves then end users (and administrators): - Need to remember (or know) less things; - Need to type less; - Have fewer chances to break the working state of stuff, which in turn spares people time (Google'ing, Bug reports, your response, etc.) Not that I'm saying that life is easy, but shouldn't we try to bring ease to life if we can? From this K.I.S.S. point-of-view is wildly guessed that slapadd not setuid'ing was a bug. If you wish to prevent future events for other users, you should consider this a bug. I won't bother you again. I'll just 'chown openlpad:openldap /usr/sbin/slapadd' and then 'chmod a+s /usr/sbin/slapadd' as it should be more than enough to avoid future events for me. Thank your time and promptly reply. I don't know if you get payd for doing this stuff, but you should. Starting in November Google for 'science ,not fiction'. Thanks again. Pedro RA Pierangelo Masarati escreveu: > pedrorandrade(a)gmail.com wrote: > > >> One workaround is issuing 'sudo -u openldap slapadd ...' to avoid >> chown'ing afterwards. >> > > What you call a workaround is actually The Right Thing (TM). There is > no way to setuid() tools simply because there's no need to, as they can > be run with the right identity. The only reason slapd can be setuid() > is that it needs to start as root in order to bind to port 389, and > **then** setuid() before doing anything else. Running programs as the > correct user is normal UNIX administration - or should OpenLDAP also > document ls, rm, ...? > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > > >

1 0

ITS#5166
by ando＠sys-net.it 04 Oct '07

04 Oct '07

I've added a comment in slapadd(8), slapindex(8) about the need to make sure commands are either executed with the right identity, or their ownership is changed after execution. As a side note, if any of the tools that access the database (slapacl, slapauth, slapcat, slaptest without -u) are run with an empty environment, they'll create the environment, of course owned by the identity they've been run as. This is a known problem; they should rather refuse to operate if the environment is empty, since they need an already set up one. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

(ITS#5167) Contribution of section for admin guide covering memberof overlay
by bgmilne＠staff.telkomsa.net 03 Oct '07

03 Oct '07

Full_Name: Buchan Milne Version: 2.4.5 OS: Linux URL: ftp://ftp.openldap.org/incoming/buchan-milne-20071004-2.patch Submission from: (NULL) (196.15.129.131) I wrote a short description and example of the use of the memberof overlay for use in the placeholder in the admin guide.

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by ando＠sys-net.it 03 Oct '07

03 Oct '07

pedrorandrade(a)gmail.com wrote: > One workaround is issuing 'sudo -u openldap slapadd ...' to avoid > chown'ing afterwards. What you call a workaround is actually The Right Thing (TM). There is no way to setuid() tools simply because there's no need to, as they can be run with the right identity. The only reason slapd can be setuid() is that it needs to start as root in order to bind to port 389, and **then** setuid() before doing anything else. Running programs as the correct user is normal UNIX administration - or should OpenLDAP also document ls, rm, ...? p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by rra＠stanford.edu 03 Oct '07

03 Oct '07

pedrorandrade(a)gmail.com writes: > After testing, I think the problem is with slapadd. > The above command (slapd -l base.ldif) created one 'objectClass.bdb' > file owned by root:root. > After chown'ing that bdb file all works again. > Furthermore, if one skips the slapd start/stop steps, slapadd populates > the database dir and all created files are owned by root. > Is this a bug or not? Shouldn't 'slapadd' setuid();? If you're going to run slapd as a non-root user, you need to be sure that all data initialization is done as the user you're running slapd as. If any of that data initialization is done by the Debian packaging scripts (the upgrade scripts, the init script, and so forth), that's a bug in the Debian package. Please submit a bug to Debian so that we can fix it there. I doubt that anything here is a bug in OpenLDAP. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5166) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 03 Oct '07

03 Oct '07

OK. Pierangelo Masarati is right all the way. I'm not using the latest release. I'm using the one that debian provides. C programming doesn't 'chroot's, it 'setuid();'s. My mistake. Sorry. I'm not into the internals of openldap, but Pierangelo sure is and setuid() **before** reading the configuration files makes sense (which reminds me i should 'chown' those too), so I was far off. But, one issue remains: When I deleted the files, /etc/init.d/slapd start /etc/init.d/slapd stop slapd -l base.ldif /etc/init.d/slapd start ldapdelete failed again with the same error: (80) entry index delete failed After testing, I think the problem is with slapadd. The above command (slapd -l base.ldif) created one 'objectClass.bdb' file owned by root:root. After chown'ing that bdb file all works again. Furthermore, if one skips the slapd start/stop steps, slapadd populates the database dir and all created files are owned by root. Is this a bug or not? Shouldn't 'slapadd' setuid();? One workaround is issuing 'sudo -u openldap slapadd ...' to avoid chown'ing afterwards. Oh, and yes Pierangelo, I make mistakes. Lots of them, unfortunately, like many users. But I try not to post them in Bug reports ;)

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2007