Re: (ITS#4795) dsiallow bind_simple_unprotected
by hyc＠symas.com
hugo.monteiro(a)fct.unl.pt wrote:
> Full_Name: Hugo Monteiro
> Version: 2.3.27
> OS: GNU/Linux Debian Sarge
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (85.139.79.96)
>
>
> Though it's been deprecated for a long time now, the documentation still referes
> to dsiallow bind_simple_unprotected, leading people into mistake, and some
> headaches.
Hm, according to CVS, it was removed from the release man page slapd.conf(5)
in 2.1.21, May 2003. There's certainly no trace of it in the 2.3.27 man page.
Ah, it's still in the Admin Guide... You should be more specific next time.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 11 months
(ITS#4795) dsiallow bind_simple_unprotected
by hugo.monteiro＠fct.unl.pt
Full_Name: Hugo Monteiro
Version: 2.3.27
OS: GNU/Linux Debian Sarge
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (85.139.79.96)
Though it's been deprecated for a long time now, the documentation still referes
to dsiallow bind_simple_unprotected, leading people into mistake, and some
headaches.
Keep up the good work.
Cheers,
Hugo Monteiro.
16 years, 11 months
Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it
robb(a)wtg.cw.com wrote:
> Full_Name: Robert Brooks
> Version: 2.3.31
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (62.49.19.14)
>
>
> an ldapsearch like this works
>
> ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" cn
>
> dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org
> cn: Robert Brooks
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> however this does not:
>
> ldapsearch -x -b "dc=sql,dc=example,dc=org" "cn=Robert Brooks" dn cn
>
> # search result
> search: 2
> result: 65 Object class violation
>
> # numResponses:
>
This is working just fine in HEAD/re23 (using the built-in test data):
bash-3.00$ ../clients/tools/ldapsearch -x -H ldap://:9011 -b
dc=example,dc=com -LLL cn=*mit* cn dn
# refldap://localhost:9012/dc=example,dc=com??sub
dn: cn=Mitya Kovalev,dc=example,dc=com
cn: Mitya Kovalev
That's why I suspect it's related to some issue (or inconsistency)
within your data/metadata. Could you post more?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 11 months
Re: (ITS#4785) back-sql objectclass searches fail unless there is data in ldap_entry_objclasses
by ando＠sys-net.it
robb(a)wtg.cw.com wrote:
> objectclass searches fail (with back-sql/mysql) if there is no data in the
> ldap_entry_objclasses table. Just a simple dummy entry like this is enough to
> fix the problem.
>
I see. A solution I see would be to use UNION to merge the results of a
query with and one without the outer join to ldap_entry_objclasses.
This, however, requires some extensive code manipulation, and likely
would be much less efficient, so I believe the workaround of having one
row in ldap_entry_objclasses is better.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com
On December 28, 2006 10:06:40 AM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
> Frank Cusack wrote:
>>
>> Oh, in that case I am definitely missing a lot. Since my understanding
>> of the timeout value passed to ldap_sasl_bind() is that it is a *bind*
>> timeout, which I assumed would be because some artibrary SASL mechanism
>> might take some arbitrarily long amount of time. If there is no bind
>> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout
>> passed to ldap_sasl_bind() should just be the connect() timeout then.
> ldap_sasl_bind() cannot be passed any timeout. What timeout are you
> referring to?
grrr ... I would have sworn there was a timeout arg! I must have
confused it with ldap_search(). The Netscape API does not have a
timeout arg either. I'd implemented my thread wrapper (w/ timeout)
before I learned of the LDAP_OPT_NETWORK_TIMEOUT option
(LDAP_X_OPT_CONNECT_TIMEOUT for Netscape API). I guess when I found
that option, I falsely remembered that ldap_sasl_bind_s() had a
timeout arg.
> I must disagree with the above. As far as I understand.
> LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time
> out as required. ldap_sasl_bind() should return as soon as the packet
> with the request has been sent, and the rest of the timeout policy for
> the bind only part should be dealt with by the client using the
> ldap_result() timeout arg as appropriate. I've recently tested that
> behavior for customers who wanted some certain timelimit on all
> operations, not just searches, and that required some extensive
> modifications to the proxy backends, but the client library (libldap) was
> not touched at all. In that case, the code basically uses
> ldap_sasl_bind() to wrap simple binds (that's what the proxy backends
> mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as expected.
> I can't speak for truly SASL bind as I didn't experiment timeouts with
> that.
Sounds right. In the case of a truly SASL bind where there might be a
long delay, async ldap_sasl_bind() should be enough.
Thanks for your patience.
-frank
16 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it
Frank Cusack wrote:
>
> Oh, in that case I am definitely missing a lot. Since my understanding
> of the timeout value passed to ldap_sasl_bind() is that it is a *bind*
> timeout, which I assumed would be because some artibrary SASL mechanism
> might take some arbitrarily long amount of time. If there is no bind
> timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout
> passed to ldap_sasl_bind() should just be the connect() timeout then.
ldap_sasl_bind() cannot be passed any timeout. What timeout are you
referring to?
>> ldap_initialize() doesn't actually establish any connection,
>> it just sets up the handler, and the connection is established by the
>> first operation that requires it. the asynchronous bind, muck like any
>> other asynchronous operation, simply returns after sending the packet(s)
>> containing the request.
>
> That much I do understand. (Although I thought the async bind()
> functions
> weren't actually implemented async.)
They are.
>
>> But, of course, the first of them requires the
>> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT
>> comes into play. Doing a really asynchronous connect() implies
>> returning
>> some sort of LDAP_X_INPROGRESS, keeping track of the status of the
>> connection and polling it for response for each subsequent call until
>> the
>> connection is established before actually sending any request. In this
>> sense the change should be intrusive: in this design, client code should
>> be able to handle the LDAP_X_INPROGRESS return code and resubmit the
>> request until the connection is ready. A "smarter" design would cache
>> the request, poll for connect() response during calls to ldap_result(),
>> and submit the actual request when the connection is established.
>
> Sure, I understand that also (now).
>
> What I'm saying is that most folks probably don't really need an async
> connect(), they just need a non-blocking one that returns in some known
> amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it
> only controls the connect() part, and not the subsequent bind (important
> since you can only get to connect() via the ldap_bind() or other
> calls, ie
> there is no ldap_connect() and ldap_open() is deprecated). But a new
> LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it.
I must disagree with the above. As far as I understand.
LDAP_OPT_NETWORK_TIMEOUT does what you expect: it makes connect() time
out as required. ldap_sasl_bind() should return as soon as the packet
with the request has been sent, and the rest of the timeout policy for
the bind only part should be dealt with by the client using the
ldap_result() timeout arg as appropriate. I've recently tested that
behavior for customers who wanted some certain timelimit on all
operations, not just searches, and that required some extensive
modifications to the proxy backends, but the client library (libldap)
was not touched at all. In that case, the code basically uses
ldap_sasl_bind() to wrap simple binds (that's what the proxy backends
mostly do), and using LDAP_OPT_NETWORK_TIMEOUT makes it work as
expected. I can't speak for truly SASL bind as I didn't experiment
timeouts with that.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com
On December 28, 2006 9:34:36 AM +0100 Pierangelo Masarati <ando(a)sys-net.it>
wrote:
> fcusack(a)fcusack.com wrote:
>> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is
>> close to the desired functionality. AFAICT it implements a *separate*
>> timeout for the connect() (and maybe unbind/close()?) part of an ldap
>> connection. Why someone would want to distinguish between connect()
>> and bind I don't know, especially when they don't get feedback about
>> how long connect() took.
>>
>> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT
>> which would be the total time for connect() and bind, given that
>> non-blocking connect() is already implemented. That would probably
>> solve a lot of folk's need for a working async bind.
>>
>>
> I think you're missing a point: there's no bind timeout because there's
> no need for it. The delay (or the hang) you likely see when dong
> ldap_sasl_bind() is actually spent doing a connect() to establish a
> connection.
Oh, in that case I am definitely missing a lot. Since my understanding
of the timeout value passed to ldap_sasl_bind() is that it is a *bind*
timeout, which I assumed would be because some artibrary SASL mechanism
might take some arbitrarily long amount of time. If there is no bind
timeout, then why is LDAP_OPT_NETWORK_TIMEOUT implemented? The timeout
passed to ldap_sasl_bind() should just be the connect() timeout then.
> ldap_initialize() doesn't actually establish any connection,
> it just sets up the handler, and the connection is established by the
> first operation that requires it. the asynchronous bind, muck like any
> other asynchronous operation, simply returns after sending the packet(s)
> containing the request.
That much I do understand. (Although I thought the async bind() functions
weren't actually implemented async.)
> But, of course, the first of them requires the
> connection to be established, and that's where LDAP_OPT_NETWORK_TIMEOUT
> comes into play. Doing a really asynchronous connect() implies returning
> some sort of LDAP_X_INPROGRESS, keeping track of the status of the
> connection and polling it for response for each subsequent call until the
> connection is established before actually sending any request. In this
> sense the change should be intrusive: in this design, client code should
> be able to handle the LDAP_X_INPROGRESS return code and resubmit the
> request until the connection is ready. A "smarter" design would cache
> the request, poll for connect() response during calls to ldap_result(),
> and submit the actual request when the connection is established.
Sure, I understand that also (now).
What I'm saying is that most folks probably don't really need an async
connect(), they just need a non-blocking one that returns in some known
amount of time. LDAP_OPT_NETWORK_TIMEOUT doesn't do that, since it
only controls the connect() part, and not the subsequent bind (important
since you can only get to connect() via the ldap_bind() or other calls, ie
there is no ldap_connect() and ldap_open() is deprecated). But a new
LDAP_OPT_CONNECT_BIND_TIMEOUT option could do it.
-frank
16 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it
fcusack(a)fcusack.com wrote:
> Unfortunately I won't be able to contribute a patch as I've worked
> around it in my application (I created a separate thread to handle
> the ldap connect) so I can't afford to invest the time. Plus I needed
> a solution that would work with the Netscape API as well as OpenLDAP.
>
> I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is
> close to the desired functionality. AFAICT it implements a *separate*
> timeout for the connect() (and maybe unbind/close()?) part of an ldap
> connection. Why someone would want to distinguish between connect()
> and bind I don't know, especially when they don't get feedback about
> how long connect() took.
>
> It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT
> which would be the total time for connect() and bind, given that
> non-blocking connect() is already implemented. That would probably
> solve a lot of folk's need for a working async bind.
>
>
I think you're missing a point: there's no bind timeout because there's
no need for it. The delay (or the hang) you likely see when dong
ldap_sasl_bind() is actually spent doing a connect() to establish a
connection. ldap_initialize() doesn't actually establish any
connection, it just sets up the handler, and the connection is
established by the first operation that requires it. the asynchronous
bind, muck like any other asynchronous operation, simply returns after
sending the packet(s) containing the request. But, of course, the first
of them requires the connection to be established, and that's where
LDAP_OPT_NETWORK_TIMEOUT comes into play. Doing a really asynchronous
connect() implies returning some sort of LDAP_X_INPROGRESS, keeping
track of the status of the connection and polling it for response for
each subsequent call until the connection is established before actually
sending any request. In this sense the change should be intrusive: in
this design, client code should be able to handle the LDAP_X_INPROGRESS
return code and resubmit the request until the connection is ready. A
"smarter" design would cache the request, poll for connect() response
during calls to ldap_result(), and submit the actual request when the
connection is established.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
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
------------------------------------------
16 years, 11 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by fcusack＠fcusack.com
On December 22, 2006 10:56:40 AM +0100 Pierangelo Masarati
<ando(a)sys-net.it> wrote:
> fcusack(a)fcusack.com wrote:
>> But still you can do the bind async, and just close the fd on the client
>> side on timeout. I don't see why connect() timeout can't be handled
>> the same way. (ignoring the problem that there is no API call AFAICT
>> to just drop the connection)
>>
> I'll note that there's been some interest in that area --- I loosely have
> the same need (see
> <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but
> unfortunately it's not in my priority list, considering that it might
> have relevant impact on the client library.
Unfortunately I won't be able to contribute a patch as I've worked
around it in my application (I created a separate thread to handle
the ldap connect) so I can't afford to invest the time. Plus I needed
a solution that would work with the Netscape API as well as OpenLDAP.
I did find LDAP_OPT_NETWORK_TIMEOUT, which I didn't try, but which is
close to the desired functionality. AFAICT it implements a *separate*
timeout for the connect() (and maybe unbind/close()?) part of an ldap
connection. Why someone would want to distinguish between connect()
and bind I don't know, especially when they don't get feedback about
how long connect() took.
It should be easy (?) to add something like LDAP_OPT_CONNECT_BIND_TIMEOUT
which would be the total time for connect() and bind, given that
non-blocking connect() is already implemented. That would probably
solve a lot of folk's need for a working async bind.
-frank
16 years, 11 months
