openldap-bugs

openldap-bugs@openldap.org

1 participants
20997 discussions

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 04 Oct '07

04 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 04 Oct '07

04 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 04 Oct '07

04 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 04 Oct '07

04 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

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: > Full_Name: Pedro RA > Version: 2.3.30-5 > OS: Debian 4.1.1-21 > URL: > Submission from: (NULL) (85.139.209.115) The latest release is 2.3.38. > When slapd is starting, and no database exists, slapd creates a new one with the > wrong permissions (user:root, group:root) > This probably is caused by slapd creating the database before chroot. Probably you mean before setuid(); chroot has nothing to do with the identity a process is running as. > The before-chroot creation of the database is the bug. The database is opened (and thus created, if it doesn't exist) only **after** setuid(). In fact, setuid() (and chroot() occur **before** even reading the configuration file. If it were like you say, the files would have been created **before** even knowing in which directory they should be located. > When this happens ldap-delete operations fail with: > ldap_delete: Internal (implementation specific) error (80) > additional info: entry index delete failed Probably you unintentionally performed some operation that created the files before starting slapd. 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) Wrong DBD's database permissions when slapd starts
by pedrorandrade＠gmail.com 03 Oct '07

03 Oct '07

Full_Name: Pedro RA Version: 2.3.30-5 OS: Debian 4.1.1-21 URL: Submission from: (NULL) (85.139.209.115) When slapd is starting, and no database exists, slapd creates a new one with the wrong permissions (user:root, group:root) This probably is caused by slapd creating the database before chroot. The before-chroot creation of the database is the bug. When this happens ldap-delete operations fail with: ldap_delete: Internal (implementation specific) error (80) additional info: entry index delete failed A working workaround is setting the right permissions to DBD files. In my system (Debian Etch 4.1.1-21, openldap 2.3.30-5) the command is: chmod -r openldap:openldap /var/lib/ldap

1 0

Issues with syncrepl and mirrormode
by Pierangelo Masarati 03 Oct '07

03 Oct '07

We're experiencing some strange issues with mirrormode; I don't have the whole picture at hand, right now, and I haven't been able to create the issue in a repeatable manner, however it happens regularly. The scenario is: 2 mirror-mode servers, each with 2 databases, plus back-config, replicated using syncrepl refreshAndPersist. We notice occasional sigsegv, and we could finally get a core dump, which contains #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 665 for (j=0; !BER_BVISNULL( &sc2->ctxcsn[j] ); j++) { (gdb) bt full #0 0x080e0e6f in compare_csns (sc1=0x33a96a80, sc2=0x33a96aa0, which=0x33a9682c) at ../../../servers/slapd/syncrepl.c:665 i = 0 j = 0 match = 0 text = 0x80e0e1a "\201� #1 0x080e7385 in do_syncrep2 (op=0x33a96d40, si=0x919c548) at ../../../servers/slapd/syncrepl.c:990 i = Variable "i" is not available. (gdb) p *sc1 $2 = {ctxcsn = 0x9981310, octet_str = {bv_len = 60, bv_val = 0x9d2b680 "rid=004,sid=000,csn=20070925132254.897919Z#000000#000#000000"}, rid = 4, sid = 0, numcsns = 1, sids = 0x9ce3120, sc_next = {stqe_next = 0x0}} (gdb) p *sc2 $3 = {ctxcsn = 0x0, octet_str = {bv_len = 20, bv_val = 0x9c299f0 "rid=004,sid=000,csn="}, rid = 4, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} p sc1->ctxcsn[0] $4 = {bv_len = 40, bv_val = 0x9e98cf0 "20070925132254.897919Z#000000#000#000000"} (gdb) p sc1->ctxcsn[1] $5 = {bv_len = 0, bv_val = 0x0} (gdb) p sc1->sids[0] $6 = 0 (gdb) p sc1->sids[1] $7 = 159661424 (gdb) p sc2->ctxcsn[0] $8 = {bv_len = 0, bv_val = 0x0} (gdb) p sc2->sids[0] $9 = 0 Line numbers may be slightly off because of minimal customization which should not impact this functionality. Mi first question is: is "rid=004,sid=000,csn=" a legitimate cookie? If it is, the code must account for (not) calling compare_csns() when the ctxcsn member of either struct sync_cookie is NULL. In that case, I suggest the patch Index: servers/slapd/syncrepl.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/syncrepl.c,v retrieving revision 1.361 diff -u -r1.361 syncrepl.c --- servers/slapd/syncrepl.c 29 Sep 2007 14:11:28 -0000 1.361 +++ servers/slapd/syncrepl.c 1 Oct 2007 12:25:05 -0000 @@ -985,7 +985,13 @@ if ( !BER_BVISNULL( &syncCookie.octet_str ) ) { slap_parse_sync_cookie( &syncCookie, NULL ); - compare_csns( &syncCookie_req, &syncCookie, &m ); + m = 0; + if ( syncCookie.ctxcsn ) { + compare_csns( &syncCookie_req, &syncCookie, &m ); + } else { + /* otherwise it would be dereferenced few lines below */ + assert( !refreshDeletes ); + } } } if ( ber_peek_tag( ber, &len ) == So the second question, assuming the above cookie is legitimate, would be: is it legitimate that the above cookie will only occur with refreshDelete unset? 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 ---------------------------------------

2 16

Re: (ITS#5162) Bus Error - core dumped
by hyc＠symas.com 03 Oct '07

03 Oct '07

piotr.tarnowski(a)us.edu.pl wrote: > Full_Name: Piotr Tarnowski (DrFugazi) > Version: 2.3.38 > OS: Solaris 10 U4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (155.158.96.61) > > > Hello, > > I compiled the newest version of OpenLDAP (2.3.38) on Solaris 10 U4 (8/07) > system. > I tried many times with many compilation options, but I still have an error with > 'gmake test': > >>>>>> Starting test001-slapadd ... > running defines.sh > Running slapadd to build slapd database... > Starting slapd on TCP/IP port 9011... > Using ldapsearch to retrieve all the entries... > Waiting 5 seconds for slapd to start... > 4378 Bus Error - core dumped > Waiting 5 seconds for slapd to start... Please read the FAQ http://www.openldap.org/faq/index.cgi?file=59 for information on how to obtain a trace. -- -- 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

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