(ITS#5097) slapo-refint apply to subtree renaming
by zhangweiwu＠realss.com
Full_Name: Zhang Weiwu
Version: 2.3.37
OS: Gentoo Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (218.193.55.195)
It would be nice if referential integrity is maintained during subtree
renaming.
entries:
dn: cn=Wang,ou=sales,o=example.com
...
dn: o=Su,ou=sales,o=example.com
manager: cn=Wang,ou=sales,o=example.com
do this:
$ ldapmodrdn ou=sales,o=example.com ou=sales,ou=marketing,o=example.com
Expected result
dn: cn=Wang,ou=sales,ou=marketing,o=example.com
...
dn: o=Su,ou=sales,ou=marketing,o=example.com
manager: cn=Wang,ou=sales,ou=marketing,o=example.com
...
I marked this as a bug rather than feature request because this is the expected
behavior for using with hdb backend.
16 years, 1 month
Re: (ITS#5095) back-sql concurrency issues
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> In this sense I think it's meaningless to share
> handles for write operations based on the client connection. All in all, the
> same user is always used to access the DB, and access control is done by the
> backend, while there's no guarantee the client will serialize requests. So a
> separate pool of handles could be maintained and used for write operations only;
> handles wouldn't need to be created all times, they can be reused. Only, they
> need to be used exclusively by one operation, so that SQLTransact() is only
> called for the specified sequence of operations. The pool could be fixed size,
> deferring operations when busy, or grow on request.
Actually, there's no need to cache handles based on the connection or
so. It's better to have connections cached per-thread, to make sure
they can only be used one at a time.
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
---------------------------------------
16 years, 1 month
(ITS#5095) back-sql concurrency issues
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD/re23
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (81.72.89.40)
Submitted by: ando
I believe there are (at least) two issues with back-sql:
1) cached db handle AVL access in backsql_get_db_conn() is not protected by
mutex, as insertion/deletion.
2) cached db handles are shared by operations performed by the same client
connection, so concurrent operations use the same db handle. I believe each
write operation should use a separate handle in order to be atomic.
Issue (1) will be fixed shortly; issue (2) will be fixed as soon as I finish
rewriting db handle code. In this sense I think it's meaningless to share
handles for write operations based on the client connection. All in all, the
same user is always used to access the DB, and access control is done by the
backend, while there's no guarantee the client will serialize requests. So a
separate pool of handles could be maintained and used for write operations only;
handles wouldn't need to be created all times, they can be reused. Only, they
need to be used exclusively by one operation, so that SQLTransact() is only
called for the specified sequence of operations. The pool could be fixed size,
deferring operations when busy, or grow on request.
p.
16 years, 1 month
(ITS#5094) shutting down multiple ppolicy instances yields double-free
by mbackes＠symas.com
Full_Name: Matthew Backes
Version: 2.3.x, head
OS: all
URL:
Submission from: (NULL) (132.241.73.19)
slapo-ppolicy's close method frees the static pwcons without checking to see if
someone else is using or has freed it already.
This issue appears at shutdown when trying to use slapo-ppolicy on multiple
backends.
Revisions 1.105 and 1.106 to ppolicy.c (in HEAD) fix this problem.
16 years, 1 month
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no
ando(a)sys-net.it writes:
> The "right" solution would be to protect the identity of the rootdn
> with ACLs, so that regular users cannot add/modify it.
Good idea, but that too depends on your policy. If you you have a cron
job or whatever which updates entries, including that of the rootdn, you
may not want it to have full rootdn access. If nothing else, it's a bit
like logging in as root instead of as a regular user - if you screw up
you have the opportunity to create much more havoc.
I wonder if we need a rootpolicy config parameter to tune the details of
all this. Then we can set a fairly paranoid default, and people who
need it to work differently can override.
(Another thing I remember someone asked about was to only accept rootdn
login from some specific IP address. But now that I think of it, normal
ACLs could ensure that if he had the password in an entry instead of in
rootpw.)
--
Hallvard
16 years, 1 month
Re: (ITS#5092) page size value of 1.2.840.113556.1.4.319 control
by randolf.werner＠sap.com
Hi,
oh my god what have i started here. Please don't try to convince me that
standards are important and slapd pricecly implents RFC 2696, i was
already convinced of that before i started the discussion. Anyway i like
to resond to Howard Chu because he mentioned something dangerous and
wrong regarding Active Directory (somewhat of topic here) but i like to
avaoid people following his suggestion:
Howard Chu <hyc(a)symas.com> wrote:
>> Here is why i believe others might run into the same issue. If you
need
>> to create a ldap client dealing with big search results for various
LDAP
>> directories you had to use 1.2.840.113556.1.4.319 even if you are
only
>> interested in collecting the entire result otherwise you would fail
with
>> Active Directory.
>
>Nonsense. You simply ask your AD administrator to raise the default
sizelimit,
>the same way you would ask an OpenLDAP administrator to do the same
thing.
Well about 6 years ago when i first noticed this problem, i asked
Microsoft about that limit and yes you can use ntdsutil.exe to set
MaxPageSize to a higher limit:
http://support.microsoft.com/kb/315071/en-us
But it is strongly recommend to not change it!!!! Over the years i have
seen quite some Active Directories customers and many of them are very
afraid when you ask them you change some configuration or extending the
schema. In 2001 SAP's IT set MaxPageSize=10000 for a few weeks as a
temporary workaround until i was able to provide a real solution. That
was a long time ago and today SAP's and probably most other companies
Active Directories are running with default values.
1.2.840.113556.1.4.319 and MaxPageSize had not been invented to make our
life more difficult. A good article about it is e.g.
http://searchwinit.techtarget.com/tip/0,289483,sid1_gci1265206,00.html.
I like to close with Gary Olsen's conclusion "The best practice for
setting MaxPageSize is to leave it alone."
Best regards
Randolf
16 years, 1 month
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>> The back-bdb behavior sounds right: It should remain possible to have
>> the rootdn's password in an entry instead of in slapd.conf. Among other
>> things, if the site has routines for regular password changes and "your
>> password is getting old" warnings, those will then cover rootdn as well.
>
> (But aging out the administrator's password is a good way to lock
> yourself out of your system.
Sure, so it depends on just how central that password is. But if I've
ignored a "your password is getting too old" warning for an admin user
and it gets disabled I've screwed up anyway, I prefer to set things up
to err on the side of caution. Though if it's even hard to log in to
the server machine and fix things there, I'd be in trouble.
> Note that ppolicy always lets the rootdn
> past all policy checks for this reason.)
Actually I've never used ppolicy, so I was thinking of our site's
automatic emails when we need to change our passwords.
>> OTOH if such an entry and rootpw both exist, I think it's a bug to
>> accept both passwords. I think an existing rootpw should override the
>> entry's password, that's safest and least surprising (if the admin sets
>> rootpw and someone else manages to create an entry with dn: <rootdn>).
>
> I disagree; this behavior has existed for a long time and there are probably
> people out there relying on it.
Good point. I would still like to get rid of it though. Even if it
takes an extra slapd.conf keyword.
> This isn't much different from the fact that
> userPassword itself is multivalued. I seem to recall this behavior being
> documented somewhere, can't find the reference at the moment.
I disagree - the difference is that rootpw vs. userPassword are stored
in different places and different people can modify or create them.
The rootpw doc in slapd.conf(5) looks misleading to me - at least it's
easy to read it differently from how it works.
I'm getting a deja vu feeling here, but I'm not sure from which
discussion...
>> A few icky issues:
>>
>> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside
>> the database's DIT, it would be possible to create such an entry with
>> a password. We could advise people to use a DN outside the database
>> suffix in this case, and/or accept 'rootpw' with no parameter as
>> explicitly refusing Simple Bind with the rootdn.
>
> I don't think these cases merit any special consideration.
OK. Well, I might do something more general to the doc which touches on
it anyway if I think of a better way to write it.
>> - back-null's "bind on" (accept Simple Bind with any password).
>> Maybe in this case it's best to treat rootdn without rootpw as
>> "reject simple bind as rootdn", like your patch does.
>
> If "bind on" means "accept Simple Bind with any password" then rootpw
> should be irrelevant here. Of course, for back-null the rootdn itself is
> pretty meaningless.
I looked cross-eyed at that code. I meant bind off. Nevermind.
--
Hallvard
16 years, 1 month
