openldap-technical

openldap-technical@openldap.org

22 participants
9789 discussions

Re: mdb broken under OpenBSD
by Howard Chu 05 Aug '17

05 Aug '17

Paul B. Henson wrote: >> From: Howard Chu >> Sent: Friday, August 4, 2017 4:23 AM >> >> Nice work, thanks for the update. > > So 10 of the mdb tests ended up failing; a couple because slapd failed to start, a bunch because ldapadd failed, and one because the script that evidently was executable per the -x test moments before suddenly wasn't found? There doesn't seem to be any log info or other remnants of the tests left over once they are done running to determine why they failed? Unless I missed something; what does one do to check on a test to see why it failed? Thanks… By default, all test output is in the testrun directory. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

SASL EXTERNAL binds and sasl-secprops minssf > 0
by David Hawes 05 Aug '17

05 Aug '17

With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS client auth) bind on a connection succeeds, but subsequent SASL EXTERNAL binds on the same connection fail with: slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak when: sasl-secprops minssf=128 In previous OpenLDAP versions, both the initial and subsequent SASL EXTERNAL binds succeed due to the bug in #8568. This was a misconfiguration on my part (I should have kept the default of 0), but I wonder if the initial SASL bind should also fail. It seems to succeed because tls_ssf is used in connection.c: slap_sasl_external( c, c->c_tls_ssf, &authid ); [1] http://www.openldap.org/its/index.cgi/Software%20Bugs?id=8568;selectid=8568

1 0

Re: mdb broken under OpenBSD
by Howard Chu 04 Aug '17

04 Aug '17

Paul B. Henson wrote: > On Thu, Aug 03, 2017 at 02:20:29PM -0700, Paul B. Henson wrote: > >> From my initial look, mdb_env_create() successfully sets mdb->mi_dbenv, >> it's still valid in mdb_db_open(), but by the time it reaches >> be->be_entry_put in slapadd() it's NULL :(. > > It turned out it was only sometimes NULL. The culprit was actually the local > OpenBSD patch that was added to mdb_db_open() to ensure MDB_WRITEMAP is always > set: > > if ( !(flags & MDB_WRITEMAP) ) { > Debug( LDAP_DEBUG_ANY, > LDAP_XSTRING(mdb_db_open) ": database \"%s\" does not have writemap. " > "This is required on systems without unified buffer cache.\n", > be->be_suffix[0].bv_val, rc, 0 ); > goto fail; > } > > There were two problems with it; first, it accesses the local flags variable > before it is initialized to mdb->mi_dbenv_flags shortly thereafter, so > the value is random and the if block nondeterministically triggers, and > second, it doesn't assign a failure value to rc before it jumps to fail:, > so the function returns successfully but with a closed be. > > mdb has been disabled for a while, so I'm guessing the first issue might > have occurred over time as backend.c changed and the patch was just > blindly updated without testing. The second issue I'm not sure about. So much for OpenBSD's vaunted attention to detail. > > I temporarily tweaked it to always enable MDB_WRITEMAP That would be the simplest approach. > so I could run the > mdb test suite (which doesn't have it enabled for everything) and so far > it seems to be working. > > I would hope that this simple issue isn't why they've had it disabled all > this time, but I guess I'll see what happens with the full test suite > as it progresses. > Nice work, thanks for the update. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: mdb_dbi_open and threads
by Howard Chu 03 Aug '17

03 Aug '17

Hallvard Breien Furuseth wrote: > On 22. mai 2017 14:00, Howard Chu wrote: >> Muhammed Muneer wrote: >>> Hallvard wrote >> >>> "With threads 1 and 2 coexisting? When thread 2 called mdb_dbi_open(), >>> thread 1's prospect of using mdb_dbi_open() at all was lost." >>> >>> Yeah with both coexisting. Thats what I thought. > > Sorry, I should have said with _transactions_ #1 and #2 coexisting, > _transaction_ #1's prospect of using mdb_dbi_open() at all was lost. > Transaction #3 in thread #1 can use it if it stared after txn#2 ended. > > Anyway, just forget about being clever with DBIs. LMDB does not support > DBI cleverness, that's one of its trade-offs for speed and simplicity. Exactly. >> If you want to use dbi_open in multiple threads then put it in your own >> wrapper function, protected by a mutex. > > Wait, what? mdb_dbi_open() isn't coded to handle concurrent txns > calling it, regardless of any mutexes the caller has. In particular, > it does not use nor update the environment's numdbs, so the two > transactions could end up creating the same DBI for different DBs. Yes. This is only safe if you also close the dbi in the same txn that opened it. Which you are probably doing, if you are opening and closing on the fly. > >> Naturally you will also have to wrap dbi_close the same way. > > If we did support this, txn_commit() of the txn which used dbi_open() > would also need the mutex. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

3 4

Re: mdb broken under OpenBSD
by Howard Chu 03 Aug '17

03 Aug '17

Paul B. Henson wrote: > I was interested in using openldap under OpenBSD; they currently have > mdb disabled as they say it is broken. That OS lacks a unified buffer > cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but > supposedly theoretically it should work with that. I tried running the > mdb tests, and it immediately segfaults: > > Program terminated with signal 11, Segmentation fault. > > 2773 flags |= env->me_flags & MDB_WRITEMAP; > > It looks like mdb_txn_begin is being passed a NULL env? I haven't started > poking around yet to see why that might be, but I thought I'd just toss this > out there in case an expert had a thought before I spent a lot of time on > it :). Thanks... OpenBSD's lack of a unified buffer cache is a pretty glaring deficiency, yes. Have to say, since getting nowhere discussing that feature with them, I personally have written off supporting it. For the trace you're showing, you'll have to debug the slapadd invocation and find out why env is NULL. Also use current (2.4.45) source, at least. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 2

mdb broken under OpenBSD
by Paul B. Henson 03 Aug '17

03 Aug '17

I was interested in using openldap under OpenBSD; they currently have mdb disabled as they say it is broken. That OS lacks a unified buffer cache, so mdb can only be used with the MDB_WRITEMAP option enabled, but supposedly theoretically it should work with that. I tried running the mdb tests, and it immediately segfaults: Program terminated with signal 11, Segmentation fault. 2773 flags |= env->me_flags & MDB_WRITEMAP; It looks like mdb_txn_begin is being passed a NULL env? I haven't started poking around yet to see why that might be, but I thought I'd just toss this out there in case an expert had a thought before I spent a lot of time on it :). Thanks... #0 0x000016210db057c5 in mdb_txn_begin (env=0x0, parent=0x0, flags=0, ret=0x16210df6fec0) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/../../../libraries/libl mdb/mdb.c:2773 txn = (MDB_txn *) 0xf ntxn = (MDB_ntxn *) 0x0 rc = 0 size = 0 tsize = 32639 #1 0x000016210db224df in mdb_tool_entry_put (be=0x1623ccbdd200, e=0x16235a80c008, [47/9401] text=0x7f7ffffeeb90) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/back-mdb/tools.c:624 rc = 0 mdb = (struct mdb_info *) 0x1623c3580000 op = {o_hdr = 0x0, o_tag = 0, o_time = 0, o_tincr = 0, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = { rs_modlist = 0x0, rs_e = 0x0}, oq_bind = {rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = { rs_scope = 0, rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\0', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 31 times>, o_controls = 0x0, o_authz = {sai_method = 0, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} ohdr = {oh_opid = 0, oh_connid = 0, oh_conn = 0x0, oh_msgid = 0, oh_protocol = 0, oh_tid = 0x0, oh_threadctx = 0x0, oh_tmpmemctx = 0x0, oh_tmpmfuncs = 0x0, oh_counters = 0x0, oh_log_prefix = '\0' <repeats 255 times>} __func__ = "mdb_tool_entry_put" #2 0x000016210dac8329 in slapadd (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/slapadd.c:456 textbuf = '\0' <repeats 255 times> textlen = 256 erec = {e = 0x16235a80c008, lineno = 1, nextline = 18} bvtext = {bv_len = 256, bv_val = 0x7f7ffffeebd0 ""} thr = 0x16210dd8cd78 id = 140187732470848 prev = (Entry *) 0x0 ldifrc = 1 rc = 0 stat_buf = {st_mode = 4294896512, st_dev = 32639, st_ino = 140187732470584, st_nlink = 990767968, st_uid = 5667, st_gid = 0, st_rdev = 0, st_atim = {tv_sec = 179931522, tv_nsec = 48}, st_mtim = {tv_sec = 24342436749856, tv_nsec = 24341375494144}, st_ctim = { tv_sec = 24343378665241, tv_nsec = 140187732470664}, st_size = 0, st_blocks = 140187732470664, st_blksize = 990767968, st_flags = 5667, st_gen = 0, __st_birthtim = {tv_sec = 179915312, tv_nsec = 48}} #3 0x000016210da02d7a in main (argc=8, argv=0x7f7ffffeee58) at /usr/obj/ports/openldap-2.4.44/openldap-2.4.44/servers/slapd/main.c:664 i = 0 no_detach = 0 rc = 1 urls = 0x0 username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 8 waitfds = {331804096, 5667} g_argc = 8 g_argv = (char **) 0x7f7ffffeee58 configfile = 0x0 configdir = 0x0 serverName = 0x7f7ffffef122 "slapd" serverMode = 1 scp = (struct sync_cookie *) 0x0 scp_entry = (struct sync_cookie *) 0x0 debug_unknowns = (char **) 0x0 syslog_unknowns = (char **) 0x0 serverNamePrefix = 0x16210ddb6ec5 "" l = 1 slapd_pid_file_unlink = 0 slapd_args_file_unlink = 0 firstopt = 1 __func__ = "main"

1 0

Re: searching userPassword value
by Howard Chu 02 Aug '17

02 Aug '17

Quanah Gibson-Mount wrote: > --On Wednesday, August 02, 2017 6:28 PM -0400 David Magda > <dmagda(a)ee.ryerson.ca> wrote: > >> Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. >> >> Thanks for any info. > > userPassword is base64 encoded, so no, you can't do that. False. The base64 encoding only happens in the ldapsearch tool just before it prints the result on stdout. The userPassword schema definition has no substring matching rule. And you should already know to check the schema definition for questions like this. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: searching userPassword value
by Quanah Gibson-Mount 02 Aug '17

02 Aug '17

--On Wednesday, August 02, 2017 6:28 PM -0400 David Magda <dmagda(a)ee.ryerson.ca> wrote: > Doing an "ldapsearch […] '(userpassword={SHA}*'" gets zero results. > > Thanks for any info. userPassword is base64 encoded, so no, you can't do that. You could find all the values, and then decode them. Or you could decode a specific value for a given user to see what sort of hash it is using. I'd probably use perl or python. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

searching userPassword value
by David Magda 02 Aug '17

02 Aug '17

Hello, Is there a way to search the value of the userPassword attribute? Specifically I’m hoping to determining to whether it begins with {SHA}, {CRYPT}, etc. Using the (olc)rootdn account is fine; it doesn’t have to be a regular user as this would be a rare/manual operational need. Doing an “ldapsearch […] ‘(userpassword={SHA}*'" gets zero results. Thanks for any info. Regards, David

1 0

Blacklists of simple values in LDAP attribute constraints overlay?
by Florian Best 02 Aug '17

02 Aug '17

Hello, I am searching for a way to add an LDAP constraint on attributes which prevents setting specific values. For example, I want to prevent that the attribute "uid" is equal to (case insensitive) "foo" or "bar". Using the manpage from https://linux.die.net/man/5/slapo-constraint it seems not possible, I tried a lot of things like: constraint_attribute uid set "this/uid & ([foo])" constraint_attribute uid set "this/uid & [foo]" constraint_attribute uid uri ldap:///dc=school,dc=local?forbidden?sub?(objectClass=forbiddenUsernames) constraint_attribute uid regex ^[^f][^o][^o]*$ Even if they were working (they don't) I needed to reverse the whole constraint because this would only allow me to add a whitelist while I want to add a blacklist. (Best would be If I could just add a "!" before the attribute contsraint.) I hope there is something which could help me. Best regards Florian -- Florian Best Open Source Software Engineer Univention GmbH be open Mary-Somerville-Str.1 28359 Bremen Tel.: +49 421 22232-0 Fax : +49 421 22232-99 best(a)univention.de http://www.univention.de Geschäftsführer: Peter H. Ganten HRB 20755 Amtsgericht Bremen Steuer-Nr.: 71-597-02876

2 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical