(ITS#7497) ldif_read_record line number overflow
by hyc＠OpenLDAP.org
Full_Name: Howard Chu
Version: RE24/master
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.155.233.73)
Submitted by: hyc
While trying to load a 150 million entry LDIF file using slapadd, it would
finish with no errors but only ~107 million entries were loaded. This turns out
to be because at 20 lines per record, the LDIF file contained 3 billion lines,
and the line number counter is a signed int. And in slapadd, we have the
"jumpline" option to skip some number of input lines, when resuming an
interrupted load. The jumpline defaults to 0, if the input line number is less
than the jumpline the record is silently skipped.
After reading the 2147483647th line of the file, it discards all of the rest
until hitting EOF.
Will fix this by changing the parameter to unsigned long. This is unfortunately
going to require a libldap version bump.
10 years, 10 months
Re: (ITS#7475) documenting that dynamic lists/groups overlays are mutually exclusive with the memberof overlay
by tedcheng＠symas.com
On Jan 22, 2013, at 4:40 AM, Howard Chu wrote:
> tedcheng(a)symas.com wrote:
>> Full_Name: Ted C. Cheng
>> Version: trunk
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (76.174.253.197)
>>
>>
>> Document enhancement request:
>>
>> Dynamic lists/groups do not involve group entry modification. As a result, they
>> cannot be used with the memberof overlay.
Would the above text, in one single paragraph, be good enough for the documentation?
>>
>> It would be great to document explicitly, man pages and admin guide, that
>> dynamic lists/groups overlays and memberof overlay are mutually exclusive.
>
> If you have suggested text, please submit the patch here.
>
Ted C. Cheng
Symas Corporation
10 years, 10 months
Re: (ITS#7496) Segemtation fault in mdb_entry_decode
by hyc＠symas.com
meike.stone(a)googlemail.com wrote:
> Full_Name: Meike Stone
> Version: 2.4.33 and git
> OS: Linux / SLES11 SP2
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.200.138.3)
>
>
> I use a Database with about 1,500,000 entires and 2,5GByte ldif from slapcat.
> This database was exported from our production system running bdb-backend.
>
> The Problem exist in Version 2.4.33, therefore I took the slapd source from git
> (2013/01/21) and I compiled slapd with debugging symbols.
> Thread 1 (Thread 0x7f738b21c700 (LWP 19394)):
> #1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at
> search.c:720
> scopeok = 1
> edata = {mv_size = 0, mv_data = 0x7f74bbb99728}
This indicates that the entry being debugged is actually zero bytes, i.e. it's
not a valid entry at all. Nodes like this get stored in the database during
slapadd when a child entry gets added before its parent; a zero-byte stub is
stored as a placeholder for the missing parent. When you ran slapadd you
should have seen warning messages about missing entries, telling you that your
LDIF is incomplete.
We can prevent the SEGV but your database is still invalid because your LDIF
is invalid.
> mdb = 0x7f760eff4010
> id = 1156449
> cursor = 1156449
> lastid = 18446744073709551615
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 10 months
(ITS#7496) Segemtation fault in mdb_entry_decode
by meike.stone＠googlemail.com
Full_Name: Meike Stone
Version: 2.4.33 and git
OS: Linux / SLES11 SP2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.200.138.3)
I use a Database with about 1,500,000 entires and 2,5GByte ldif from slapcat.
This database was exported from our production system running bdb-backend.
The Problem exist in Version 2.4.33, therefore I took the slapd source from git
(2013/01/21) and I compiled slapd with debugging symbols.
My test configuration is simple:
--------------------------------------------
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/yast.schema
include /etc/openldap/schema/rfc2307bis.schema
include /etc/openldap/schema/my_ldap_attributes.schema
include /etc/openldap/schema/my_ldap_ObjectClasses.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
sizelimit -1
timelimit 300
disallow bind_anon
require authc
gentlehup on
tool-threads 4
serverID 001
############################
# mdb database definitions
############################
database mdb
suffix "ou=root"
rootdn "cn=admin,ou=root"
rootpw password
directory /var/lib/ldap/ldap.mdb
loglevel 256
maxsize 10737418240
envflags writemap,nometasync
index objectClass,entryUUID,entryCSN eq
index cn eq,sub
.
.
. some other own indexes here
--------------------------------------------
I started my search via:
/tmp/ol/usr/local/bin/ldapsearch -x -h localhost -w password -D
cn=admin,ou=root -b'ou=root' '(objectClass=*)' >/dev/null
and got in the syslog following meassge:
Jan 21 17:50:31 debld02 kernel: [348860.053152] slapd[19394]: segfault
at 7f760f974ce8 ip 000000000053bea1 sp 00007f738b10a650 error 4 in
slapd
[400000+227000]
Because of this, I configured the kernel to core dump:
sysctl -w kernel.core_pattern=/tmp/core
sysctl -w kernel.core_uses_pid=1
sysctl -w kernel.suid_dumpable=2
ulimit -c unlimited
ulimit -v unlimited
Here is the output from Backtrace:
(gdb) bt
#0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770,
e=0x7f738b11a828) at id2entry.c:666
#1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:720
#2 0x0000000000433d41 in fe_op_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:402
#3 0x0000000000433647 in do_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:247
#4 0x00000000004300f5 in connection_operation (ctx=0x7f738b21bb80,
arg_v=0xc3a020) at connection.c:1150
#5 0x0000000000430694 in connection_read_thread (ctx=0x7f738b21bb80, argv=0x9)
at connection.c:1286
#6 0x0000000000566c0b in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:688
#7 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f760db31c5d in clone () from /lib64/libc.so.6
#9 0x0000000000000000 in ?? ()
========================================
(gdb) bt full
#0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770,
e=0x7f738b11a828) at id2entry.c:666
have_nval = 0
mdb = 0x7f760eff4010
i = 0
j = 0
nattrs = 2600
nvals = 524289
rc = 32627
a = 0x7f73886fa060
x = 0x7f73886fa010
text = 0x1 <Address 0x1 out of bounds>
ad = 0x11a561
lp = 0x7f74bbb99738
ptr = 0x7f74bbb99738 <Address 0x7f74bbb99738 out of bounds>
bptr = 0x7f73887187e0
#1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:720
scopeok = 1
edata = {mv_size = 0, mv_data = 0x7f74bbb99728}
mdb = 0x7f760eff4010
id = 1156449
cursor = 1156449
lastid = 18446744073709551615
candidates = {18446744073709551615, 1, 18446744073709551615, 0 <repeats
130260 times>, 140145012714441, 0, 140145012852253, 8589940736, 0,
1102570112642121728, 140134232198960, 0, 0, 4294969344, 0,
144115737831604224, 140134232199008, 0, 0, 4294969344, 0, 72058143793676288, 0,
0,
140145012852253, 562962838323220, 83263594790786, 4294967296,
72058139498840072, 72058139498905608, 18446743519659032584, 122509647347719,
563035852767288, 83263594790786, 8564836354, 144115733536768008,
144115733536833544, 18446743519659032584, 122509647347719, 563035852767292,
83263594790786, 8598329346, 1102570108347285512, 1102570108347351048,
18396392677450186760, 3488165888539164681, 0 <repeats 252 times>,
140145015511498, 24, 140134232201360, 140134232201280, 0, 0, 0, 2050,
0, 0, 0, 0, 140134232201392, 140134240594784, 5912807, 0, 38654705665, 0,
8804682956800, 140134232205552, 5910925, 4294967296, 140144980134384,
17179869184, 10555744, 0 <repeats 35 times>, 4764301, 0, 0, 9576736,
140134232205088, 0, 140134232205088, 9576736, 0, 140134232201856,
5642426, 9576736, 4764202, 140134232205088, 9576768, 0, 0, 140134232201920,
4764448, 0, 9576416, 9576416, 140134232205088, 0, 9576736,
140134232205248, 4752534, 0, 4764301, 140134232205360, 12821496, 9317456,
140134232205312, 0, 140134232205312, 9317456, 0, 140134232202080,
5642426, 9317456, 4764202, 140134232205312, 9317488, 0, 0, 140134232202144,
4764448, 0, 9317136, 9317136, 140134232205312, 0, 9317456,
140134232205472, 4752534, 0, 140134232210000, 140134232205576, 140134232205552,
0 <repeats 42 times>, 3, 140134232204592, 140134232204608, 12, 3,
140145012098155, 18446730733541130240, 140134232204444, 140134232204432,
140134232204488, 0, 0, 140134232204336, 140134232213248, 0, 0, 0, 0,
0, 140134232203296, 0, 0, 0, 0, 5956991, 5956996, 0, 18446744073709551615,
140134232202872, 64, 140145015434880...}
scopes = 0x7f7389f1a010
e = 0x0
base = 0xc3a548
matched = 0x0
attrs = 0x0
mask = 5119
stoptime = 1358790564
manageDSAit = 0
tentries = -1
isc = {mt = 0xd3bd50, mc = 0xd3d840, id = 1156449, scopes =
0x7f7389f1a010, numrdns = 7, nscope = 1, rdns = {{bv_len = 19,
bv_val = 0x7f74bbba594e <Address 0x7f74bbba594e out of bounds>},
{bv_len = 19,
bv_val = 0x7f74bbba29b8 <Address 0x7f74bbba29b8 out of bounds>},
{bv_len = 9,
bv_val = 0x7f738e1bffee <Address 0x7f738e1bffee out of bounds>},
{bv_len = 19,
bv_val = 0x7f74ad2f49b4 <Address 0x7f74ad2f49b4 out of bounds>},
{bv_len = 18,
bv_val = 0x7f74ad2f4821 <Address 0x7f74ad2f4821 out of bounds>},
{bv_len = 19,
bv_val = 0x7f74a7f47696 <Address 0x7f74a7f47696 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 0, bv_val = 0x0} <repeats 2039 times>}, nrdns = {{bv_len = 19,
bv_val = 0x7f74bbba593a <Address 0x7f74bbba593a out of bounds>},
{bv_len = 19,
bv_val = 0x7f74bbba29a4 <Address 0x7f74bbba29a4 out of bounds>},
{bv_len = 9,
bv_val = 0x7f738e1bffe4 <Address 0x7f738e1bffe4 out of bounds>},
{bv_len = 19,
bv_val = 0x7f74ad2f49a0 <Address 0x7f74ad2f49a0 out of bounds>},
{bv_len = 18,
bv_val = 0x7f74ad2f480e <Address 0x7f74ad2f480e out of bounds>},
{bv_len = 19,
bv_val = 0x7f74a7f47682 <Address 0x7f74a7f47682 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 0, bv_val = 0x0} <repeats 2039 times>}}
mci = 0xd3d6b0
opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key =
0x7f760eff4010}, moi_txn = 0xd3bd50, moi_ref = 1, moi_flag = 1 '\001'}
moi = 0x7f738b10a7c0
ltid = 0xd3bd50
#2 0x0000000000433d41 in fe_op_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:402
bd = 0x836180
#3 0x0000000000433647 in do_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:247
base = {bv_len = 7, bv_val = 0xc39f97 "ou=root"}
siz = 0
off = 0
i = 0
#4 0x00000000004300f5 in connection_operation (ctx=0x7f738b21bb80,
arg_v=0xc3a020) at connection.c:1150
rc = 80
cancel = 0
op = 0xc3a020
rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0,
sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {
sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs =
0x0, r_attrs = 0x0, r_nentries = 1156423, r_v2ref = 0x0}, sru_sasl = {
r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata =
0x0}}, sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f760bc209f0
memctx = 0xa11320
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#5 0x0000000000430694 in connection_read_thread (ctx=0x7f738b21bb80, argv=0x9)
at connection.c:1286
rc = 0
cri = {op = 0xc3a020, func = 0, arg = 0x0, ctx = 0x7f738b21bb80, nullop
= 0}
s = 9
#6 0x0000000000566c0b in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:688
pool = 0x8ef460
task = 0xa11490
work_list = 0x8ef4f8
ctx = {ltu_id = 140134232213248, ltu_key = {{ltk_key = 0x42fbef,
ltk_data = 0xc39d50, ltk_free = 0x42fa3b <conn_counter_destroy>}, {
ltk_key = 0x4a2675, ltk_data = 0xa11320, ltk_free = 0x4a24a4
<slap_sl_mem_destroy>}, {ltk_key = 0x44aba4, ltk_data = 0x0,
ltk_free = 0x44aafc <slap_op_q_destroy>}, {ltk_key =
0x7f760ba1e010, ltk_data = 0xd3bd50, ltk_free = 0x53b0f7 <mdb_reader_free>}, {
ltk_key = 0x502c94, ltk_data = 0x7f7388f19010, ltk_free = 0x502c74
<search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 27 times>}}
kctx = 0x0
i = 32
keyslot = 805
hash = 2547932965
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#7 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8 0x00007f760db31c5d in clone () from /lib64/libc.so.6
No symbol table info available.
#9 0x0000000000000000 in ?? ()
No symbol table info available.
========================================
(gdb) thread apply all bt
Thread 4 (Thread 0x7f760f155700 (LWP 19386)):
#0 0x00007f760ddd6f95 in pthread_join () from /lib64/libpthread.so.0
#1 0x000000000056814b in ldap_pvt_thread_join (thread=140134240605952,
thread_return=0x0) at thr_posix.c:197
#2 0x000000000042d01e in slapd_daemon () at daemon.c:2935
#3 0x0000000000409029 in main (argc=11, argv=0x7fffd76de248) at main.c:1013
Thread 3 (Thread 0x7f738ba1d700 (LWP 19387)):
#0 0x00007f760db322e3 in epoll_wait () from /lib64/libc.so.6
#1 0x000000000042be25 in slapd_daemon_task (ptr=0xa10ec0) at daemon.c:2542
#2 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
#3 0x00007f760db31c5d in clone () from /lib64/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x7f738aa1b700 (LWP 19395)):
#0 0x00007f760ddda61c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1 0x00000000005681f3 in ldap_pvt_thread_cond_wait (cond=0x8ef490,
mutex=0x8ef468) at thr_posix.c:277
#2 0x0000000000566b6c in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:675
#3 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
#4 0x00007f760db31c5d in clone () from /lib64/libc.so.6
#5 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f738b21c700 (LWP 19394)):
#0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770,
e=0x7f738b11a828) at id2entry.c:666
#1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:720
#2 0x0000000000433d41 in fe_op_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:402
#3 0x0000000000433647 in do_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:247
#4 0x00000000004300f5 in connection_operation (ctx=0x7f738b21bb80,
arg_v=0xc3a020) at connection.c:1150
#5 0x0000000000430694 in connection_read_thread (ctx=0x7f738b21bb80, argv=0x9)
at connection.c:1286
#6 0x0000000000566c0b in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:688
#7 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
#8 0x00007f760db31c5d in clone () from /lib64/libc.so.6
#9 0x0000000000000000 in ?? ()
========================================
(gdb) thread apply all bt full
Thread 4 (Thread 0x7f760f155700 (LWP 19386)):
#0 0x00007f760ddd6f95 in pthread_join () from /lib64/libpthread.so.0
No symbol table info available.
#1 0x000000000056814b in ldap_pvt_thread_join (thread=140134240605952,
thread_return=0x0) at thr_posix.c:197
No locals.
#2 0x000000000042d01e in slapd_daemon () at daemon.c:2935
i = 0
rc = 0
#3 0x0000000000409029 in main (argc=11, argv=0x7fffd76de248) at main.c:1013
i = 11
no_detach = 0
rc = -12
urls = 0x8bf090 "ldap:/// "
username = 0x8bf0e0 "root"
groupname = 0x8bf100 "ldap"
sandbox = 0x0
syslogUser = 160
pid = 0
waitfds = {8, 9}
g_argc = 11
g_argv = 0x7fffd76de248
configfile = 0x8bf0b0 "/etc/openldap/slapd.conf"
configdir = 0x0
serverName = 0x7fffd76df6c0 "slapd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x5a4ebd ""
l = 4218987
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
Thread 3 (Thread 0x7f738ba1d700 (LWP 19387)):
#0 0x00007f760db322e3 in epoll_wait () from /lib64/libc.so.6
No symbol table info available.
#1 0x000000000042be25 in slapd_daemon_task (ptr=0xa10ec0) at daemon.c:2542
ns = 1
at = 0
nfds = 3
revents = 0x8c4700
tvp = 0x0
cat = {tv_sec = 0, tv_usec = 0}
i = 1
nwriters = 0
now = 1358790631
tv = {tv_sec = 0, tv_usec = 0}
tdelta = 1
rtask = 0x0
l = 1
last_idle_check = 1358790529
ebadf = 0
tid = 0
#2 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#3 0x00007f760db31c5d in clone () from /lib64/libc.so.6
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (Thread 0x7f738aa1b700 (LWP 19395)):
#0 0x00007f760ddda61c in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
No symbol table info available.
#1 0x00000000005681f3 in ldap_pvt_thread_cond_wait (cond=0x8ef490,
mutex=0x8ef468) at thr_posix.c:277
No locals.
#2 0x0000000000566b6c in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:675
pool = 0x8ef460
task = 0x0
work_list = 0x8ef4f8
ctx = {ltu_id = 140134223820544, ltu_key = {{ltk_key = 0x42fbef,
ltk_data = 0xb39c30, ltk_free = 0x42fa3b <conn_counter_destroy>}, {
ltk_key = 0x4a2675, ltk_data = 0xb397b0, ltk_free = 0x4a24a4
<slap_sl_mem_destroy>}, {ltk_key = 0x44aba4, ltk_data = 0xb39870,
ltk_free = 0x44aafc <slap_op_q_destroy>}, {ltk_key =
0x7f760ba1e010, ltk_data = 0xd3a3f0, ltk_free = 0x53b0f7 <mdb_reader_free>}, {
ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 28 times>}}
kctx = 0x0
i = 32
keyslot = 660
hash = 2646102676
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#3 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#4 0x00007f760db31c5d in clone () from /lib64/libc.so.6
No symbol table info available.
#5 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 1 (Thread 0x7f738b21c700 (LWP 19394)):
#0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770,
e=0x7f738b11a828) at id2entry.c:666
have_nval = 0
mdb = 0x7f760eff4010
i = 0
j = 0
nattrs = 2600
nvals = 524289
rc = 32627
a = 0x7f73886fa060
x = 0x7f73886fa010
---Type <return> to continue, or q <return> to quit---
text = 0x1 <Address 0x1 out of bounds>
ad = 0x11a561
lp = 0x7f74bbb99738
ptr = 0x7f74bbb99738 <Address 0x7f74bbb99738 out of bounds>
bptr = 0x7f73887187e0
#1 0x0000000000501d30 in mdb_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:720
scopeok = 1
edata = {mv_size = 0, mv_data = 0x7f74bbb99728}
mdb = 0x7f760eff4010
id = 1156449
cursor = 1156449
lastid = 18446744073709551615
candidates = {18446744073709551615, 1, 18446744073709551615, 0 <repeats
130260 times>, 140145012714441, 0, 140145012852253, 8589940736, 0,
1102570112642121728, 140134232198960, 0, 0, 4294969344, 0,
144115737831604224, 140134232199008, 0, 0, 4294969344, 0, 72058143793676288, 0,
0,
140145012852253, 562962838323220, 83263594790786, 4294967296,
72058139498840072, 72058139498905608, 18446743519659032584, 122509647347719,
563035852767288, 83263594790786, 8564836354, 144115733536768008,
144115733536833544, 18446743519659032584, 122509647347719, 563035852767292,
83263594790786, 8598329346, 1102570108347285512, 1102570108347351048,
18396392677450186760, 3488165888539164681, 0 <repeats 252 times>,
140145015511498, 24, 140134232201360, 140134232201280, 0, 0, 0, 2050,
0, 0, 0, 0, 140134232201392, 140134240594784, 5912807, 0, 38654705665, 0,
8804682956800, 140134232205552, 5910925, 4294967296, 140144980134384,
17179869184, 10555744, 0 <repeats 35 times>, 4764301, 0, 0, 9576736,
140134232205088, 0, 140134232205088, 9576736, 0, 140134232201856,
5642426, 9576736, 4764202, 140134232205088, 9576768, 0, 0, 140134232201920,
4764448, 0, 9576416, 9576416, 140134232205088, 0, 9576736,
140134232205248, 4752534, 0, 4764301, 140134232205360, 12821496, 9317456,
140134232205312, 0, 140134232205312, 9317456, 0, 140134232202080,
5642426, 9317456, 4764202, 140134232205312, 9317488, 0, 0, 140134232202144,
4764448, 0, 9317136, 9317136, 140134232205312, 0, 9317456,
140134232205472, 4752534, 0, 140134232210000, 140134232205576, 140134232205552,
0 <repeats 42 times>, 3, 140134232204592, 140134232204608, 12, 3,
140145012098155, 18446730733541130240, 140134232204444, 140134232204432,
140134232204488, 0, 0, 140134232204336, 140134232213248, 0, 0, 0, 0,
0, 140134232203296, 0, 0, 0, 0, 5956991, 5956996, 0, 18446744073709551615,
140134232202872, 64, 140145015434880...}
scopes = 0x7f7389f1a010
e = 0x0
base = 0xc3a548
matched = 0x0
attrs = 0x0
mask = 5119
stoptime = 1358790564
manageDSAit = 0
tentries = -1
isc = {mt = 0xd3bd50, mc = 0xd3d840, id = 1156449, scopes =
0x7f7389f1a010, numrdns = 7, nscope = 1, rdns = {{bv_len = 19,
bv_val = 0x7f74bbba594e <Address 0x7f74bbba594e out of bounds>},
{bv_len = 19,
bv_val = 0x7f74bbba29b8 <Address 0x7f74bbba29b8 out of bounds>},
{bv_len = 9,
bv_val = 0x7f738e1bffee <Address 0x7f738e1bffee out of bounds>},
{bv_len = 19,
bv_val = 0x7f74ad2f49b4 <Address 0x7f74ad2f49b4 out of bounds>},
{bv_len = 18,
bv_val = 0x7f74ad2f4821 <Address 0x7f74ad2f4821 out of bounds>},
{bv_len = 19,
bv_val = 0x7f74a7f47696 <Address 0x7f74a7f47696 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bbd <Address 0x7f74bc3d2bbd out of bounds>},
{bv_len = 0, bv_val = 0x0} <repeats 2039 times>}, nrdns = {{bv_len = 19,
bv_val = 0x7f74bbba593a <Address 0x7f74bbba593a out of bounds>},
{bv_len = 19,
bv_val = 0x7f74bbba29a4 <Address 0x7f74bbba29a4 out of bounds>},
{bv_len = 9,
bv_val = 0x7f738e1bffe4 <Address 0x7f738e1bffe4 out of bounds>},
{bv_len = 19,
bv_val = 0x7f74ad2f49a0 <Address 0x7f74ad2f49a0 out of bounds>},
{bv_len = 18,
bv_val = 0x7f74ad2f480e <Address 0x7f74ad2f480e out of bounds>},
{bv_len = 19,
bv_val = 0x7f74a7f47682 <Address 0x7f74a7f47682 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 12,
bv_val = 0x7f74bc3d2bb0 <Address 0x7f74bc3d2bb0 out of bounds>},
{bv_len = 0, bv_val = 0x0} <repeats 2039 times>}}
mci = 0xd3d6b0
opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key =
0x7f760eff4010}, moi_txn = 0xd3bd50, moi_ref = 1, moi_flag = 1 '\001'}
moi = 0x7f738b10a7c0
ltid = 0xd3bd50
#2 0x0000000000433d41 in fe_op_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:402
bd = 0x836180
#3 0x0000000000433647 in do_search (op=0xc3a020, rs=0x7f738b21ba30) at
search.c:247
base = {bv_len = 7, bv_val = 0xc39f97 "ou=root"}
siz = 0
off = 0
i = 0
#4 0x00000000004300f5 in connection_operation (ctx=0x7f738b21bb80,
arg_v=0xc3a020) at connection.c:1150
rc = 80
cancel = 0
op = 0xc3a020
rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0,
sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {
sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs =
0x0, r_attrs = 0x0, r_nentries = 1156423, r_v2ref = 0x0}, sru_sasl = {
r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata =
0x0}}, sr_flags = 0}
tag = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f760bc209f0
memctx = 0xa11320
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#5 0x0000000000430694 in connection_read_thread (ctx=0x7f738b21bb80, argv=0x9)
at connection.c:1286
rc = 0
cri = {op = 0xc3a020, func = 0, arg = 0x0, ctx = 0x7f738b21bb80, nullop
= 0}
s = 9
#6 0x0000000000566c0b in ldap_int_thread_pool_wrapper (xpool=0x8ef460) at
tpool.c:688
pool = 0x8ef460
task = 0xa11490
work_list = 0x8ef4f8
ctx = {ltu_id = 140134232213248, ltu_key = {{ltk_key = 0x42fbef,
ltk_data = 0xc39d50, ltk_free = 0x42fa3b <conn_counter_destroy>}, {
ltk_key = 0x4a2675, ltk_data = 0xa11320, ltk_free = 0x4a24a4
<slap_sl_mem_destroy>}, {ltk_key = 0x44aba4, ltk_data = 0x0,
ltk_free = 0x44aafc <slap_op_q_destroy>}, {ltk_key =
0x7f760ba1e010, ltk_data = 0xd3bd50, ltk_free = 0x53b0f7 <mdb_reader_free>}, {
ltk_key = 0x502c94, ltk_data = 0x7f7388f19010, ltk_free = 0x502c74
<search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0,
ltk_free = 0} <repeats 27 times>}}
kctx = 0x0
i = 32
keyslot = 805
hash = 2547932965
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#7 0x00007f760ddd67b6 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#8 0x00007f760db31c5d in clone () from /lib64/libc.so.6
No symbol table info available.
#9 0x0000000000000000 in ?? ()
No symbol table info available.
10 years, 10 months
Re: (ITS#7495) access filter not correctly validated if assertion attribute not requested
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms090800020408080308010509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hallvard B Furuseth wrote:
> Cannot reproduce on RedHat Linux, x86_64. But then, the info was
> rather brief. (E.g. which backend? Was that a per-backend or global
> ACL? Might some overlays or other access statements interefere?)
>=20
> Anyway, please provide a complete config and preferably LDIF which
> demonstrates the problem.
Thanks for looking it this.
As usual this is a more complex customer setup with many ACLs and several=
overlays. I tried to provide a simple example but I also see that this do=
es
not show the issue on my local machine.
I will try to strip down the complex config. But this will take a while.
Ciao, Michael.
--------------ms090800020408080308010509
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILHzCC
BT8wggQnoAMCAQICDwCmSwABAAIAivjZQ8SBvzANBgkqhkiG9w0BAQUFADB8MQswCQYDVQQG
EwJERTEcMBoGA1UEChMTVEMgVHJ1c3RDZW50ZXIgR21iSDElMCMGA1UECxMcVEMgVHJ1c3RD
ZW50ZXIgQ2xhc3MgMSBMMSBDQTEoMCYGA1UEAxMfVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBM
MSBDQSBJWDAeFw0xMjA2MDYxOTAyMTZaFw0xMzA2MDcxOTAyMTZaMCgxCzAJBgNVBAYTAkRF
MRkwFwYDVQQDDBBNaWNoYWVsIFN0csO2ZGVyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAxXZGav40rnGNLxEggBW94MILWHlfC8a23Jew5U1gPlfRTXOjjzmoaZ1uCyGdgF6M
VvuO9T1aTQNGH+OdeGe3P7Tfc/NsLJFJ2wtd8blvhmodUgse2eypiWjNOd4gZuhalBhgsQ0K
b5D6/1foghII4E264iZlJ7AJ+UYcO+GxvFWT0YMTbLckgDkZk7c3qwTozdhYvXarvqx+8Ou/
kuxpQQhac/ebzxpu0N+RHSf2KIUS0g0tEGnPtGv6iL+9QNHc4JKo9Y9KKVw3tQy+Re+FQLxB
1fPE5F+qxuD3AUENpOwkMsqWLM94ohtx3CFqLpxfUPrnKFLAHOhHEbByYGvFPwIDAQABo4IC
EDCCAgwwgaUGCCsGAQUFBwEBBIGYMIGVMFEGCCsGAQUFBzAChkVodHRwOi8vd3d3LnRydXN0
Y2VudGVyLmRlL2NlcnRzZXJ2aWNlcy9jYWNlcnRzL3RjX2NsYXNzMV9MMV9DQV9JWC5jcnQw
QAYIKwYBBQUHMAGGNGh0dHA6Ly9vY3NwLml4LnRjY2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1
c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAU6bgoHUbP/M34TpvF7ktg69g7P9EwDAYDVR0TAQH/
BAIwADBKBgNVHSAEQzBBMD8GCSqCFAAsAQEBATAyMDAGCCsGAQUFBwIBFiRodHRwOi8vd3d3
LnRydXN0Y2VudGVyLmRlL2d1aWRlbGluZXMwDgYDVR0PAQH/BAQDAgTwMB0GA1UdDgQWBBS2
KAWfTfgJ/JQ63qLGwTXYLnI+LzBiBgNVHR8EWzBZMFegVaBThlFodHRwOi8vY3JsLml4LnRj
Y2xhc3MxLnRjdW5pdmVyc2FsLWkudHJ1c3RjZW50ZXIuZGUvY3JsL3YyL3RjX0NsYXNzMV9M
MV9DQV9JWC5jcmwwMwYDVR0lBCwwKgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcDBwYK
KwYBBAGCNxQCAjAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkqhkiG9w0B
AQUFAAOCAQEAQ3bvVUpEq+cQrLpcogyt5BJNk/WvUvOHqhzyj28M9pg9hcDl1+MYl5qqj6tR
GSTLPQZyf287pcmbMwbcTGZO/gbW9v7RYcut6RauWdwKMCUmKC3J4fVfDq9ZETA2WOV68ef4
B3Gzdhghsbp3Rhp5dDmrCVKAHlafm6ZwJrEQ9P76fxnQZzRLgeKpZep5ePH5YHUB3+YaOQvJ
FG0bOXvfHhRiRG7/HW2G+yDgjHSxDz8AFzMWL/RFePqZ4pn6T/SM/qU6WEpW39MWyJNoH/Kx
QDYK8gGYuesn1ciMCTnjrvZQj0fonGTO4SfWekJRkuGrJ7dYSZRjYbDcWBBkdFLWzzCCBdgw
ggTAoAMCAQICDgboAAEAAkqWLSQM/sXJMA0GCSqGSIb3DQEBBQUAMHkxCzAJBgNVBAYTAkRF
MRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSQwIgYDVQQLExtUQyBUcnVzdENlbnRl
ciBVbml2ZXJzYWwgQ0ExJjAkBgNVBAMTHVRDIFRydXN0Q2VudGVyIFVuaXZlcnNhbCBDQSBJ
MB4XDTA5MTEwMzE0MDgxOVoXDTI1MTIzMTIxNTk1OVowfDELMAkGA1UEBhMCREUxHDAaBgNV
BAoTE1RDIFRydXN0Q2VudGVyIEdtYkgxJTAjBgNVBAsTHFRDIFRydXN0Q2VudGVyIENsYXNz
IDEgTDEgQ0ExKDAmBgNVBAMTH1RDIFRydXN0Q2VudGVyIENsYXNzIDEgTDEgQ0EgSVgwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC75pBuz2Lp6QuqthDVR+V8XSsncZpozVVt
5KLv5P7yemMRwleKyH3PjmYfZUVL64Biab1GjovFblqVGCrep/EfdRonq20yU+P7TVhiLP8Z
5cegDZotIYhZhM0d8cPIij6w5d4IJM/8QCy6QSOUu4ASiTVItoYE4AFPjLqpmPwcie0fiqHH
hpgmHnJla/7PZdkMZEsaCfVDEWBmJuMzVprJPT40anjG5VBLyM2I5DlsUCaeQCy2O3w3sqf1
3dyzUcv03IICuNc63towXA31Qt0TaVNU6YAmQjMepdfMbspmCZ+G8D2+xophEPPR/1vkstst
smUMqX0XrLonTUJczglPAgMBAAGjggJZMIICVTCBmgYIKwYBBQUHAQEEgY0wgYowUgYIKwYB
BQUHMAKGRmh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2VydHNlcnZpY2VzL2NhY2VydHMv
dGNfdW5pdmVyc2FsX3Jvb3RfSS5jcnQwNAYIKwYBBQUHMAGGKGh0dHA6Ly9vY3NwLnRjdW5p
dmVyc2FsLUkudHJ1c3RjZW50ZXIuZGUwHwYDVR0jBBgwFoAUkqR1LKSevoFE63n8isWVpesQ
dXMwEgYDVR0TAQH/BAgwBgEB/wIBADBSBgNVHSAESzBJMAYGBFUdIAAwPwYJKoIUACwBAQEB
MDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVsaW5lczAO
BgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFOm4KB1Gz/zN+E6bxe5LYOvYOz/RMIH9BgNVHR8E
gfUwgfIwge+ggeyggemGRmh0dHA6Ly9jcmwudGN1bml2ZXJzYWwtSS50cnVzdGNlbnRlci5k
ZS9jcmwvdjIvdGNfdW5pdmVyc2FsX3Jvb3RfSS5jcmyGgZ5sZGFwOi8vd3d3LnRydXN0Y2Vu
dGVyLmRlL0NOPVRDJTIwVHJ1c3RDZW50ZXIlMjBVbml2ZXJzYWwlMjBDQSUyMEksTz1UQyUy
MFRydXN0Q2VudGVyJTIwR21iSCxPVT1yb290Y2VydHMsREM9dHJ1c3RjZW50ZXIsREM9ZGU/
Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlPzANBgkqhkiG9w0BAQUFAAOCAQEAOcjE
m+6+mO5Icm+N53G2DpCM07LBFSGoRpBoX0oE8TrJaIQh2KXmBHVdn9LU8kt3QzLclctgvwJV
0KwcsMUUl5tlCsMPpR3s2Ek5lbWpvvr0HqtW56blAQiINV9nBd1EJFASIkRjefGbV2nOq9Yz
UU+N8HA7jq1ROhd/NZZraGhjthwKyfjfHV7PKxGlY+3M0MbTIG+q/GhIfm0euDpFqhKG88e9
ALXr/uoSn3MzeOcoOWjTpW3adtFO4VWVgKbgG7jNrFbvRVlHmFLbOm4msjE5aXWxLiTwpJ2X
iF4zKca1vAdAOgw9us90jEtOeiH6GzjNxEMvb7TfeO6Zkuc6HDGCA84wggPKAgEBMIGPMHwx
CzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQLExxU
QyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRlciBD
bGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wCQYFKw4DAhoFAKCCAhMwGAYJKoZI
hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMTE4MDk1MDEwWjAjBgkq
hkiG9w0BCQQxFgQU1RpOiulz4kW+ZHL3/+Odrcd/p7YwbAYJKoZIhvcNAQkPMV8wXTALBglg
hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBoAYJKwYBBAGCNxAEMYGSMIGP
MHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYDVQQL
ExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENlbnRl
ciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wgaIGCyqGSIb3DQEJEAILMYGS
oIGPMHwxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNUQyBUcnVzdENlbnRlciBHbWJIMSUwIwYD
VQQLExxUQyBUcnVzdENlbnRlciBDbGFzcyAxIEwxIENBMSgwJgYDVQQDEx9UQyBUcnVzdENl
bnRlciBDbGFzcyAxIEwxIENBIElYAg8ApksAAQACAIr42UPEgb8wDQYJKoZIhvcNAQEBBQAE
ggEANO11SaHS/pNHgOfahbUWbbKPUehk1rFyEtJsKkofAgVQ4JAmRTgOhv6vnVCSv915I3dR
uPYCaZWi8QR/lG7p1mVsjCVVSiXrGYysZ4mXnFs5TMyWQTla6FkFH6KdKLU25gbJQy1O2QXV
4enTezhwFCct+ALDMjQXS5ZbWcS3opyrslna4KNypUluj4HQ58DiLdDBnMOSvdpN3mpPheLd
oH9+vHRKiPFJQQu2bVBPwWWY4cXvha3SSHRCqDKBTRAtegjTiO1Y6R57Q6vtLFyIouMKyaEA
MDpbMCAUAmVcJmm1YTMtfMTjmyxiZyAU6YY7hb5ISHMGYJTuOofdpjsWBgAAAAAAAA==
--------------ms090800020408080308010509--
10 years, 10 months
Re: (ITS#7495) access filter not correctly validated if assertion attribute not requested
by michael＠stroeder.com
Sorry for the confusion caused by editing what I've copied from the real
system before which uses a group for several Samba DC instances.
In this example the ACL part should be more simple like this:
access to
dn.subtree="o=example"
attrs=sambaNTPassword
filter="(organizationalStatus=0)"
by dn.exact="uid=samba_dc,o=example" write
by group="cn=slapd Admins,ou=groups,o=example" =sw
by self =w
by * none
Ciao, Michael.
10 years, 10 months
(ITS#7495) access filter not correctly validated if assertion attribute not requested
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: RE24 6f33e2c
OS: Debian Squeeze
URL:
Submission from: (NULL) (2001:8d8:1fe:1:d6be:d9ff:fe06:a14f)
This is tested with RE24 built for Debian Squeeze:
It seems that ACLs are not correctly evaluated when processing a search request
if the assertion type is not requested in the search request.
Example:
access to
dn.subtree="o=example"
attrs=sambaNTPassword
filter="(organizationalStatus=0)"
by group="uid=samba_dc,o=example" write
by group="cn=slapd Admins,ou=groups,o=example" =sw
by self =w
by * none
The following search correctly returns attribute sambaNTPassword of the entry:
ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" organizationalStatus
sambaNTPassword
But this search does not return sambaNTPassword:
ldapsearch -LLL -X "dn:uid=samba_dc,o=example"
"(&(objectclass=sambaSamAccount)(uid=wtester))" sambaNTPassword
I cannot find any hint in slapd.access(5) that this is expected behaviour.
10 years, 10 months
Re: (ITS#7493) slapo-allowed: allowed* attrs are replicated
by hyc＠symas.com
masarati(a)aero.polimi.it wrote:
>> Michael Ströder wrote:
>>> hyc(a)symas.com wrote:
>>>> masarati(a)aero.polimi.it wrote:
>>>>> On 01/15/2013 07:40 PM, michael(a)stroeder.com wrote:
>>>>>
>>>>>> Please consider the attached patch which sets allowed
>>>>>> "USAGE dSAOperation". This seems to be the most appropriate USAGE
>>>>>> compara=
>>>>>> ble
>>>>>> to what's set for entryTTL in slapo-dds.
>>>>>
>>>>> No objection with this patch, since those properties were
>>>>> "arbitrarily"
>>>>> assigned to attributes defined by others to provide software
>>>>> interoperability. Unless anyone has objections, I'd commit it.
>>>>
>>>> Go ahead. Please add a comment about the origin of the schema
>>>> definitions and
>>>> these interoperability concerns.
>>>
>>> These attribute type descriptions were roughly taken from MS AD.
>>
>> I meant, please add a comment *in the patch* so it will remain in the
>> source code.
>
> There's already a detailed comment to this end in the related README,
> which links the attribute definitions on <http://msdn.microsoft.com/>.
As already noted, those links don't provide actual schema definitions, nor do
they define the USAGE. We're making a judgement call here with no
documentation to support it. We should document why we're defining it this way
so we don't have to repeat this conversation again down the road.
>
> p.
>
>>> Today I've checked the subschema of a W2K8R2 AD server:
>>> I did not find a single attribute type description with USAGE although
>>> there
>>> were attribute types formally defined in RFCs. One example is 'entryTTL'
>>> defined with "USAGE dSAOperation" in RFC 2589 which in fact was
>>> co-authored by
>>> Microsoft employees.
>>>
>>> The official Microsoft documentation is here [MS-ADA1]:
>>>
>>> http://msdn.microsoft.com/en-us/library/cc219752.aspx
>>>
>>> Ciao, Michael.
>>>
>>
>>
>>
>>
>
>
10 years, 10 months
Re: (ITS#7493) slapo-allowed: allowed* attrs are replicated
by masarati＠aero.polimi.it
> Michael Ströder wrote:
>> hyc(a)symas.com wrote:
>>> masarati(a)aero.polimi.it wrote:
>>>> On 01/15/2013 07:40 PM, michael(a)stroeder.com wrote:
>>>>
>>>>> Please consider the attached patch which sets allowed
>>>>> "USAGE dSAOperation". This seems to be the most appropriate USAGE
>>>>> compara=
>>>>> ble
>>>>> to what's set for entryTTL in slapo-dds.
>>>>
>>>> No objection with this patch, since those properties were
>>>> "arbitrarily"
>>>> assigned to attributes defined by others to provide software
>>>> interoperability. Unless anyone has objections, I'd commit it.
>>>
>>> Go ahead. Please add a comment about the origin of the schema
>>> definitions and
>>> these interoperability concerns.
>>
>> These attribute type descriptions were roughly taken from MS AD.
>
> I meant, please add a comment *in the patch* so it will remain in the
> source code.
There's already a detailed comment to this end in the related README,
which links the attribute definitions on <http://msdn.microsoft.com/>.
p.
>> Today I've checked the subschema of a W2K8R2 AD server:
>> I did not find a single attribute type description with USAGE although
>> there
>> were attribute types formally defined in RFCs. One example is 'entryTTL'
>> defined with "USAGE dSAOperation" in RFC 2589 which in fact was
>> co-authored by
>> Microsoft employees.
>>
>> The official Microsoft documentation is here [MS-ADA1]:
>>
>> http://msdn.microsoft.com/en-us/library/cc219752.aspx
>>
>> Ciao, Michael.
>>
>
>
>
>
--
Pierangelo Masarati
Associate Professor
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano
10 years, 10 months
