Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it
ali.pouya(a)free.fr wrote:
> Hi Pierangelo;
> As you requested, you find below my simplified slapd.conf.
> If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd
> cannot start.
HEAD is working as expected (slapd starts, although it cannot register
the database specific monitor info).
If a rootdn is added to the monitor database, it starts just fine.
What version are you testing? Since this is a > 2.3 specific feature,
anything earlier than HEAD will not be considered.
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
---------------------------------------
15 years, 8 months
Re: (ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>> This is while testing a custom pwdCheckModule.
>> In function check_password_quality(), char *txt is free()'d, slapd
>> crashes with "invalid pointer".
>
> The code works as designed (and as documented). Re-read the
> slapo-ppolicy(5) manpage. This ITS will be closed.
Actually I think it has a doc bug anyway. See ITS#4901: memory malloced
in one Windows DLL must be freed by the same DLL. So the manpage needs
to specify _which_ allocation function to use: either ber_memalloc() or
slap_sl_malloc(). Because proto-slap.h #defines free to ch_free, which
uses ber_memfree_x() or slap_sl_free().
--
Regards,
Hallvard
15 years, 8 months
Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr
Hi Pierangelo;
As you requested, you find below my simplified slapd.conf.
If I comment the line "access to dn.sub="cn=monitor" by * read", then slapd
cannot start.
Best regards
Ali
====================================================
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
access to attrs=userPassword
by anonymous auth
by * none
access to dn.sub="cn=monitor" by * read
access to *
by * none
database monitor
database bdb
serverID 1
suffix "c=fr"
rootdn cn=admin,ou=internal,o=gouv,c=fr
rootpw {SSHA}1QuNDW3pqQDP93tMcyXo6ClZBJ2VP5XG
directory /produits/bdb/data
checkpoint 1000000 10
index objectClass,entryCSN,entryUUID eq
index uid,cn eq,sub,pres
overlay syncprov
syncprov-checkpoint 1000 10
syncprov-sessionlog 1000
syncprov-reloadhint TRUE
overlay ppolicy
ppolicy_hash_cleartext
15 years, 8 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de
Hello...
ando(a)sys-net.it wrote:
> You pointed out a misalignment between documentation and code, which
> was the result of a continuous evolution of both in an attempt to
> make dynlist as general as possible while letting it keep
> contradictory configurations under control. The checks currently
> implemented resulted too strict, so I relaxed them. Maybe they are
> now too relaxed (you just get a warning if you do something odd, but
> then the oddest thing you could do would result at most in slowing
> down the DSA you admin). Please check if the current code satisfies
> your requirements so that the change can be released ASAP.
I checked out CVS "HEAD" code, if that is, what
cvs -z3 co -P openldap
with
CVSROOT=:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP
does, configured and built it. I might have used a slightly different
configuration than my current production environment, but after building
I was able to run slapd without even a warning about the following
configuration:
overlay dynlist
dynlist-attrset posixGroup memberURL
dynlist-attrset groupOfURLs memberURL owner
So, the relaxation of the config checking seems to be successful.
Thanks for your fast reaction to my issue report.
bye
Christian
--
Christian Marg mail: mailto:marg@rz.tu-clausthal.de
Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
Germany ICQ : <on request>
15 years, 8 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by ando＠sys-net.it
I think you need to realize that dynlist (and dynamic groups in general)
represent an abuse of the LDAP data model. You pointed out a
misalignment between documentation and code, which was the result of a
continuous evolution of both in an attempt to make dynlist as general as
possible while letting it keep contradictory configurations under
control. The checks currently implemented resulted too strict, so I
relaxed them. Maybe they are now too relaxed (you just get a warning if
you do something odd, but then the oddest thing you could do would
result at most in slowing down the DSA you admin). Please check if the
current code satisfies your requirements so that the change can be
released ASAP. Don't expect dynlist to do all you want it to do, and
exactly as you want it, because it needs to satisfy other requirements
as well. If you want to design specs for dynamic groups, or dynamic
lists, maybe an ITS is not the right forum.
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
---------------------------------------
15 years, 8 months
(ITS#4998) overlays/ppolicy.c: invalid pointer due to free() of unallocated buffer
by msl＠calivia.com
Full_Name: Michael Steinmann
Version: 2.3.35 / HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.254.173.218)
This is while testing a custom pwdCheckModule.
In function check_password_quality(), char *txt is free()'d, slapd crashes with
"invalid pointer".
Core was generated by `servers/slapd/slapd -f etc/openldap/slapd.conf -h
ldap://localhost:10389/ -d 9'.
Program terminated with signal 6, Aborted.
#0 0xb7b3a0b6 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb7b3a0b6 in raise () from /lib/libc.so.6
#1 0xb7b3b841 in abort () from /lib/libc.so.6
#2 0xb7b7019b in __libc_message () from /lib/libc.so.6
#3 0xb7b75de2 in malloc_printerr () from /lib/libc.so.6
#4 0x08089bb8 in ch_free (ptr=0xb7c3aff4) at ch_malloc.c:139
#5 0x08119833 in check_password_quality (cred=0x2, pp=<value optimized out>,
err=0xb752becc, e=0x8285998) at ppolicy.c:650
#6 0x0811ac59 in ppolicy_modify (op=0x8285028, rs=0xb752c1c4) at
ppolicy.c:1751
#7 0x080c7134 in overlay_op_walk (op=0x8285028, rs=0xb752c1c4, which=op_modify,
oi=0x822f488, on=0x822f578) at backover.c:498
#8 0x080c758d in over_op_func (op=0x8285028, rs=0xb752c1c4, which=op_modify) at
backover.c:560
#9 0x080a117b in passwd_extop (op=0x8285028, rs=0xb752c1c4) at passwd.c:284
#10 0x0809f611 in fe_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:215
#11 0x0809fb79 in do_extended (op=0x8285028, rs=0xb752c1c4) at extended.c:180
#12 0x08070589 in connection_operation (ctx=0xb752c238, arg_v=0x8285028) at
connection.c:1133
#13 0x08143ae3 in ldap_int_thread_pool_wrapper (xpool=0x820eb40) at tpool.c:478
#14 0xb7c43f8a in start_thread () from /lib/libpthread.so.0
#15 0xb752c480 in ?? ()
#16 0xb752c480 in ?? ()
#17 0xb752c480 in ?? ()
#18 0xb752c480 in ?? ()
#19 0x00000000 in ?? ()
Patch below fixes the issue.
Index: ppolicy.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v
retrieving revision 1.98
diff -r1.98 ppolicy.c
652d651
< free(txt);
15 years, 8 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de
Hello Kurt,
Kurt Zeilenga wrote:
> On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote:
[...]
>> posixGroup and groupOfURLs are both "structural" objectclasses so
>> an entry is either a "groupofURL" or a "posixGroup", never both.
>
> Yes, but an entry can belong to both. That is, an entry's structural
> class could inherit from both of these classes.
I didn't know that multiple inheritance existed in an LDAP schema. Or
did you mean that there is an inheritance chain like: "top - person -
organisationalPerson - inetOrgPerson"?
In the latter case - if dynlist honored inheritance - the rules should
be made clear:
1st example:
dynlist-attrset person personURL
dynlist-attrset inetOrgPerson inetOrgPersonURL
No problem: An inetOrgPerson-Object is encountered and if both
*URL-Attributes were defined, both would be expanded.
2nd example:
dynlist-attrset person someURL
dynlist-attrset inetOrgPerson someURL
In this case there would have to be rule for matching: Either
first-match or most exact match.
>> And in this case the memberURL can have different meanings
>> according to the Objectclass it is used in.
>
> That's called bad schema design. If an attribute has is specified to
> have different meaning when used with X then when used with Y, it's
> not only unclear what meaning the attribute as when used with both X
> and Y, but also used without either X or Y.
Ok, I was beeing unclear: memberURL of course has no different meaning
in two different group type OCs - it is the URL that lists the members
of that group.
Only difference is that OC 'A' might not allow attribute 'S' returned by
the LDAP URL used for expansion in OC 'B', while OC 'B' might not allow
attribute 'T' returned by the LDAP URL used for expansion in OC 'A'.
Still both LDAP URLs are values of the Attribute "memberURL". And no
schema constraint I know of can control what an LDAP URL specifies.
I could add multiple Attribute-Descriptions (SUP labeledURI) like:
uidexpansionURL - containing only LDAP URLS like
ldap:///<base>?uid?<scope>?<filter>
mailexpansionURL - containing only LDAP URLS like
ldap:///<base>?mail?<scope>?<filter>
but now I've got two different objectclasses that should list a set of
mail adresses - what should I do?
Should I really define two attributes
OCAmailexpansionURL
and
OCBmailexpansionURL
just to satisfy current(?) dynlist configuration rules? I think that
would be bad schema design: Different attributes for values meaning the
same.
> Note that attributes may be added to an entry which are not allowed
> by any of the classes the entry belongs to... (see DIT content
> rules).
The addition of the "extensibleObject" OC is the closest thing I've seen
to what I understand from that sentence. I just don't understand what
this has to do with Pierangelo believing that expansion of the same URL
attribute in different object classes should be forbidden.
bye
Christian
--
Christian Marg mail: mailto:marg@rz.tu-clausthal.de
Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
Germany ICQ : <on request>
15 years, 8 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by kurt＠OpenLDAP.org
On Jun 2, 2007, at 2:47 PM, marg(a)rz.tu-clausthal.de wrote:
> Hello...
>
> ando(a)sys-net.it wrote:
>> marg(a)rz.tu-clausthal.de wrote:
>>
>>> I found a behaviour issue with the dynlist overlay configuration:
>>>
>>> I tried the following configuration:
>>>
>>> overlay dynlist
>>> dynlist-attrset posixGroup memberURL
>>> dynlist-attrset groupOfURLs memberURL owner
>>
>> The reason of that check is that the same attribute "memberURL" could
>> otherwise be used by both group classes to expand.
>
> [...]
>
>> However, I believe something like
>>
>> dynlist-attrset posixGroup memberURL
>> dynlist-attrset groupOfURLs memberURL
>>
>> should still be forbiden, otherwise the same "memberURL" would expand
>> twice. This, strictly speaking, is not an issue, as duplicates would
>> simply be discarded, but it would cause unnecessary overhead. Right
>> now, I have decided to turn this check into a config-time warning.
>
> Hmm - I object.
>
> posixGroup and groupOfURLs are both "structural" objectclasses so an
> entry is either a "groupofURL" or a "posixGroup", never both.
Yes, but an entry can belong to both. That is, an entry's structural
class could inherit from both of these classes.
> And in
> this case the memberURL can have different meanings according to the
> Objectclass it is used in.
That's called bad schema design. If an attribute has is specified
to have different meaning when used with X then when used with Y,
it's not
only unclear what meaning the attribute as when used with both X and
Y, but also used without either X or Y. Note that attributes may be
added to an entry which are not allowed by any of the classes the
entry belongs to... (see DIT content rules).
> Otherwise I'd have to create an Attribute for every expansion I
> want to
> use - that can't be right!
>
> You are right for expansions in auxillary OCs, of course! They
> shouldn't
> be using the same attribute...
>
>> Please test and report.
>
> Will do, sometime soon.
>
> bye
> Christian
> --
> Christian Marg mail: mailto:marg@rz.tu-clausthal.de
> Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
> D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
> Germany ICQ : <on request>
>
>
15 years, 8 months
Re: (ITS#4989) Quirk in Dynlist overlay configuration
by marg＠rz.tu-clausthal.de
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig98A1F9874D1718E82ABEA8E9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hello.
Pierangelo Masarati wrote:
> Christian Marg wrote:
>=20
>> Hmm - I object.
>>
>> posixGroup and groupOfURLs are both "structural" objectclasses so an
>> entry is either a "groupofURL" or a "posixGroup", never both.
>=20
> OK, my example was stupid. But you got the idea below.
>=20
>> You are right for expansions in auxillary OCs, of course! They shouldn=
't
>> be using the same attribute...
Couldn't the config file check test if the OC is structural/auxilliary?
Do you expand for OC InetOrgPerson if an expansion was configured for OC
Person?
I can configure an expansion for the abstract objectclass "TOP" without
any error message (that doesn't really make sense, I know, because they
don't exist in the directory) - if you'd respect inheritance that would
be a fun thing to do - every Objectclass is (in-)directly inherited from
"TOP" ;)
bye
Christian
--=20
Christian Marg mail: mailto:marg@rz.tu-clausthal.de
Rechenzentrum TU Clausthal web : http://www.rz.tu-clausthal.de
D-38678 Clausthal-Zellerfeld fon : 05323/72-2043
Germany ICQ : <on request>
--------------enig98A1F9874D1718E82ABEA8E9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGYtNyXwu7mUb3ymMRAoO/AJ9vdGCDBj3yGCUYjkOEppngJRWdzACffxB0
WuO/HvOk3KkVUzg5k6VA20g=
=Y3xR
-----END PGP SIGNATURE-----
--------------enig98A1F9874D1718E82ABEA8E9--
15 years, 8 months
