openldap-bugs September 2012

openldap-bugs@openldap.org

29 participants
107 discussions

Re: (ITS#7364) mdb: clean up POSIX semaphores on environment close.
by h.b.furuseth＠usit.uio.no 17 Sep '12

17 Sep '12

libmdb now removes semaphores more thoroughly - at init, and after ITS#7377 at exit failure. Anything else - like SysV semaphores - can wait until someone shows up who cares about it. [Re-sent after originally sending to wrong ITS: #7363] -- Hallvard

1 0

Re: (ITS#7363) libmdb should use POSIX semaphores on non-apple BSD systems too.
by h.b.furuseth＠usit.uio.no 17 Sep '12

17 Sep '12

I've cleaned up preprocessor names, and remove semaphores more thoroughly - at init, and after ITS#7377 at at exit failure. Anything else - like SysV semaphores - can wait until someone shows up who cares about it. -- Hallvard

1 0

(ITS#7393) slapd crash when changing an attribute name to an existing name
by ddick＠cpan.org 17 Sep '12

17 Sep '12

Full_Name: David Dick Version: 2.4.26 OS: Fedora 16 URL: Submission from: (NULL) (124.148.129.18) When changing the NAME of an attribute to the name of an existing attribute, the slapd process crashes. The following set of statements in ldif format will crash the server; The cn={12} was chosen as the next available schema index and may need to be adjusted appropriately. dn: cn={12}crashme,cn=schema,cn=config changetype: add objectClass: olcSchemaConfig cn: {12}crashme olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'SmtpHost' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) dn: cn={12}crashme,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( 1.3.6.1.4.1.70001.2.1 NAME 'MailHost' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

1 0

Re: (ITS#7388) [PATCH] MozNSS: ignore certdb 'sql:' prefix when checking directory existence
by jvcelak＠redhat.com 16 Sep '12

16 Sep '12

Hello Howard, > The patch looks syntactically correct. But SQL, seriously? As if TLS > handshakes weren't slow enough already, you want to slow them down > even > further by looking up certs in an SQL database? this is nothing new. Mozilla NSS supports SQL backend (SQLite) for storing certificates since 3.12 (== Firefox 3) I think. The reason, why the new format was introduced is mainly because of problems with accesing the database from multiple processes. It is described on the following page in a great detail: https://wiki.mozilla.org/NSS_Shared_DB I can't tell anything about the performance because I haven't tried. > Aside from questioning the wisdom of such an inefficient approach, > there are > other philosophical problems with this patch. It seems to be just the > latest > in a continuing stream of one-off patches. Are we going to get yet > another > special case patch from you guys when some other new certDB type > comes along? One Fedora user e-mailed me recently and wanted my help with setting the OpenLDAP server to use the database in "new" sql format. This patch is the result. I do not think that any other backend except the legacy and this one is supported. Otherwise, I would write the patch more generally. I will check with MozNSS people and let you know. > This approach is unmaintainable and does nothing to inspire > confidence in the > quality of thinking going into this code. > > You're working on a security library. We expect a lot better thought > to go > into these things. I fully understand and expect that you will have some feedback on our patches - which is happening right now. MozNSS crypto backend works quite fine, but there are still some problems in certain corner situations. The backend is not as mature as OpenSSL one. I'm really trying to fix them all and to make OpenLDAP a better piece of software. Jan

1 0

Re: (ITS#7392) ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by daniel＠pluta.biz 16 Sep '12

16 Sep '12

Hi, applying the patch linked below both previously mentioned operations produce the following log Operation 1: log level 128 ========================== 505573f8 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 505573f8 => dn: [1] dc=example,dc=org 505573f8 => dn: [2] dc=example,dc=org 505573f8 => acl_get: [2] matched 505573f8 => acl_get: [2] attr owner 505573f8 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 505573f8 => acl_mask: to value by "uid=user,dc=example,dc=org", (=0) 505573f8 <= check a_dn_at: owner 505573f8 <= acl_mask: [1] applying read(=rscxd) (stop) 505573f8 <= acl_mask: [1] mask: read(=rscxd) 505573f8 => slap_access_allowed: delete access denied by read(=rscxd) 505573f8 => access_allowed: no more rules 505573f8 => access_allowed: result not in cache (owner) Operation 2: log level 128 ========================== 505573f8 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 505573f8 => dn: [1] dc=example,dc=org 505573f8 => dn: [2] dc=example,dc=org 505573f8 => acl_get: [2] matched 505573f8 => acl_get: [2] attr owner 505573f8 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 505573f8 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 505573f8 => acl_mask: to self, attr "owner" 505573f8 <= check a_dn_at: owner 505573f8 <= acl_mask: [1] applying read(=rscxd) (stop) 505573f8 <= acl_mask: [1] mask: read(=rscxd) 505573f8 => slap_access_allowed: delete access denied by read(=rscxd) 505573f8 => access_allowed: no more rules ftp://ftp.openldap.org/incoming/Daniel-Pluta-120916.patch DISCLAIMER: It's not heavyly tested. I don't know whether the patch causes negative sideeffects elsewhere.

1 0

(ITS#7392) ACL a_dn.a_self is skipped in case of "acl_mask: to all values ..."
by daniel＠pluta.biz 15 Sep '12

15 Sep '12

Full_Name: Daniel Pluta Version: Linux OS: OPENLDAP_REL_ENG_2_4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.167.49.115) Hi, given this (simplyfied and thus quite strange looking) sample acl statement: access to dn.one="dc=example,dc=org" attrs=@groupOfNames by dnattr=owner selfread by users write the first by clause ("by dnattr=owner selfread") is only honored in case of an access "to value", like for example: #Operation 1 (log see below): dn: cn=group,dc=example,dc=org changetype: modify delete: owner owner: uid=user,dc=example,dc=org - but is skipped in case of an access "to all values", like for example: #Operation 2 (log see below): dn: cn=group,dc=example,dc=org changetype: modify delete: owner - In case (hopefully) this is not the intended behavior. The following "comment-patch" could be the place to start further investigations. Thanks a lot. diff --git a/servers/slapd/acl.c b/servers/slapd/acl.c index 4b72342..89cb9ae 100644 --- a/servers/slapd/acl.c +++ b/servers/slapd/acl.c @@ -1170,7 +1170,14 @@ slap_acl_mask( !is_at_syntax( desc->ad_type, SLAPD_NAMEUID_SYNTAX )) continue; /* check if the target is an attribute. */ - if ( val == NULL ) continue; + if ( val == NULL ) { + /* check all values whether a_dn.a_self is contained */ + + /* if a_dn.a_self is contained: implicitly set val to a_dn.a_self */ + + /* else: continue */ + continue; + } /* a DN must be present */ if ( BER_BVISEMPTY( &op->o_ndn ) ) { Operation 1: log level 128 ========================== 5054ed13 => access_allowed: result not in cache (owner) 5054ed13 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 5054ed13 => dn: [1] dc=example,dc=org 5054ed13 => dn: [2] dc=example,dc=org 5054ed13 => acl_get: [2] matched 5054ed13 => acl_get: [2] attr owner 5054ed13 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 5054ed13 => acl_mask: to value by "uid=user,dc=example,dc=org", (=0) 5054ed13 <= check a_dn_at: owner 5054ed13 <= acl_mask: [1] applying read(=rscxd) (stop) 5054ed13 <= acl_mask: [1] mask: read(=rscxd) 5054ed13 => slap_access_allowed: delete access denied by read(=rscxd) 5054ed13 => access_allowed: no more rules Operation 2: log level 128 ========================== 5054ed29 => access_allowed: result not in cache (owner) 5054ed29 => access_allowed: delete access to "cn=group,dc=example,dc=org" "owner" requested 5054ed29 => dn: [1] dc=example,dc=org 5054ed29 => dn: [2] dc=example,dc=org 5054ed29 => acl_get: [2] matched 5054ed29 => acl_get: [2] attr owner 5054ed29 => acl_mask: access to entry "cn=group,dc=example,dc=org", attr "owner" requested 5054ed29 => acl_mask: to all values by "uid=user,dc=example,dc=org", (=0) 5054ed29 <= check a_dn_pat: users 5054ed29 <= acl_mask: [2] applying write(=wrscxd) (stop) 5054ed29 <= acl_mask: [2] mask: write(=wrscxd) 5054ed29 => slap_access_allowed: delete access granted by write(=wrscxd) 5054ed29 => access_allowed: delete access granted by write(=wrscxd) 5054ed29 acl: internal mod entryCSN: modify access granted 5054ed29 acl: internal mod modifiersName: modify access granted 5054ed29 acl: internal mod modifyTimestamp: modify access granted slapd.conf: =========== include /tmp/example/core.schema include /tmp/example/cosine.schema include /tmp/example/sociopath.schema pidfile /tmp/example/run/slapd.pid argsfile /tmp/example/run/slapd.args access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by * read database mdb suffix "dc=example,dc=org" rootdn "cn=Manager,dc=example,dc=org" rootpw secret directory /tmp/example/data index objectClass eq add_content_acl on access to dn.base="dc=example,dc=org" attrs=children by users write #simplyfied, thus probably strange looking, but nevertheless valid: access to dn.one="dc=example,dc=org" attrs=@groupOfNames by dnattr=owner selfread by users write access to dn.one="dc=example,dc=org" by self read by users read by anonymous auth

1 0

Re: (ITS#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Howard Chu wrote: > Thanks, fixed in master. Seems to be fixed in RE24 f5231cc6175be6c591345b6c4c069ba2859a1f0a Thanks. Ciao, Michael.

1 0

Re: (ITS#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by hyc＠symas.com 14 Sep '12

14 Sep '12

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: RE24 42baa43cb92bc52081d24d925a584dd430437d75 > URL: > Submission from: (NULL) (79.227.150.68) > > > With recent fixes for mdb in RE24 42baa43cb92bc52081d24d925a584dd430437d75 > slapcat does not work anymore while slapd can access the DB quite well: Thanks, fixed in master. > > 50537559 mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore > from backup! > 50537559 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open > failed! (13) > slap_startup failed > /home/michael/backups/openldap2.4-stroeder.de-accesslog-2012-09-14T20:20:09.ldif.bz2: > ok > 50537559 mdb_db_open: database "dc=stroeder,dc=de" cannot be opened, err 13. > Restore from backup! > 50537559 backend_startup_one (type=mdb, suffix="dc=stroeder,dc=de"): bi_db_open > failed! (13) > slap_startup failed > /home/michael/backups/openldap2.4-stroeder.de-daten-2012-09-14T20:20:09.ldif.bz2: > ok > > -- -- 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#7391) mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup!
by michael＠stroeder.com 14 Sep '12

14 Sep '12

Full_Name: Version: OS: RE24 42baa43cb92bc52081d24d925a584dd430437d75 URL: Submission from: (NULL) (79.227.150.68) With recent fixes for mdb in RE24 42baa43cb92bc52081d24d925a584dd430437d75 slapcat does not work anymore while slapd can access the DB quite well: 50537559 mdb_db_open: database "cn=accesslog" cannot be opened, err 13. Restore from backup! 50537559 backend_startup_one (type=mdb, suffix="cn=accesslog"): bi_db_open failed! (13) slap_startup failed /home/michael/backups/openldap2.4-stroeder.de-accesslog-2012-09-14T20:20:09.ldif.bz2: ok 50537559 mdb_db_open: database "dc=stroeder,dc=de" cannot be opened, err 13. Restore from backup! 50537559 backend_startup_one (type=mdb, suffix="dc=stroeder,dc=de"): bi_db_open failed! (13) slap_startup failed /home/michael/backups/openldap2.4-stroeder.de-daten-2012-09-14T20:20:09.ldif.bz2: ok

1 0

Re: (ITS#7390) slapschema crashes with rwm-rewriteMap slapd
by michael＠stroeder.com 14 Sep '12

14 Sep '12

hyc(a)symas.com wrote: > Fixed in git master. I've retested with git master and it works. Thanks! Ciao, Michael.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2012