OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/5798
Full headers

From: ando@sys-net.it
Subject: MMR/mirror mode circumvents schema check
Compose comment
Download message
State:
0 replies:
6 followups: 1 2 3 4 5 6

Major security issue: yes  no

Notes:

Notification:


Date: Sat, 8 Nov 2008 14:22:41 GMT
From: ando@sys-net.it
To: openldap-its@OpenLDAP.org
Subject: MMR/mirror mode circumvents schema check
Full_Name: Pierangelo Masarati
Version: HEAD/re24
OS: irrelevant
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.63.140.131)
Submitted by: ando


When syncrepl is configured, schema checking is switched off.  As a consequence,
schema checking does not occur for all writes, including direct writes from
clients when MMR/MM is in use.

Internal writes performed by syncrepl should be marked as such, in order to
disable schema checking only when appropriate.

p.


Followup 1

Download message
Date: Sat, 08 Nov 2008 16:32:34 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
ando@sys-net.it wrote:
> Full_Name: Pierangelo Masarati
> Version: HEAD/re24
> OS: irrelevant
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (82.63.140.131)
> Submitted by: ando
> 
> 
> When syncrepl is configured, schema checking is switched off.  As a
consequence,
> schema checking does not occur for all writes, including direct writes from
> clients when MMR/MM is in use.
> 
> Internal writes performed by syncrepl should be marked as such, in order to
> disable schema checking only when appropriate.

It all seems to boil down to the fact that syncrepl schemachecking is 
off by default.  So, not specifying any results in having multimasters 
with schemachecking disabled, which is not desirable.  I recommend 
schema checking be on by default.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 2

Download message
Date: Sat, 08 Nov 2008 16:47:27 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: Howard Chu <hyc@symas.com>
CC: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
Howard Chu wrote:
> ando@sys-net.it wrote:
>> ando@sys-net.it wrote:
>>> Full_Name: Pierangelo Masarati
>>> Version: HEAD/re24
>>> OS: irrelevant
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (82.63.140.131)
>>> Submitted by: ando
>>>
>>>
>>> When syncrepl is configured, schema checking is switched off.  As a

>>> consequence,
>>> schema checking does not occur for all writes, including direct 
>>> writes from
>>> clients when MMR/MM is in use.
>>>
>>> Internal writes performed by syncrepl should be marked as such, in 
>>> order to
>>> disable schema checking only when appropriate.
>>
>> It all seems to boil down to the fact that syncrepl schemachecking is
>> off by default.  So, not specifying any results in having multimasters
>> with schemachecking disabled, which is not desirable.  I recommend
>> schema checking be on by default.
> 
> All we have to do is change the code from setting the DB flag to using 
> the per-op o_no_schema_check flag. IMO defaulting schemacheck off for 
> replication is fine because replicated entries will have been checked on 
> the master.

Well, it used to be so, but now with MMR (and mirror mode) it's no 
longer so.  Using the per-op is fine, as long as the caller consistently 
sets it.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------



Followup 3

Download message
Date: Sat, 08 Nov 2008 07:45:55 -0800
From: Howard Chu <hyc@symas.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
ando@sys-net.it wrote:
> ando@sys-net.it wrote:
>> Full_Name: Pierangelo Masarati
>> Version: HEAD/re24
>> OS: irrelevant
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (82.63.140.131)
>> Submitted by: ando
>>
>>
>> When syncrepl is configured, schema checking is switched off.  As a
consequence,
>> schema checking does not occur for all writes, including direct writes
from
>> clients when MMR/MM is in use.
>>
>> Internal writes performed by syncrepl should be marked as such, in
order to
>> disable schema checking only when appropriate.
>
> It all seems to boil down to the fact that syncrepl schemachecking is
> off by default.  So, not specifying any results in having multimasters
> with schemachecking disabled, which is not desirable.  I recommend
> schema checking be on by default.

All we have to do is change the code from setting the DB flag to using the 
per-op o_no_schema_check flag. IMO defaulting schemacheck off for replication 
is fine because replicated entries will have been checked on the master.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 4

Download message
Date: Sat, 08 Nov 2008 07:49:52 -0800
From: Howard Chu <hyc@symas.com>
To: ando@sys-net.it
CC: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
Howard Chu wrote:
> All we have to do is change the code from setting the DB flag to using the
> per-op o_no_schema_check flag. IMO defaulting schemacheck off for
replication
> is fine because replicated entries will have been checked on the master.

Of course, it was already using the per-op flag too. Probably meant to remove 
the per-DB flag and forgot to some time ago. Fixed now in HEAD.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/



Followup 5

Download message
From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
Date: Sat, 8 Nov 2008 19:49:17 +0100
To: hyc@symas.com
Cc: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
hyc@symas.com writes:
> IMO defaulting schemacheck off for replication is fine because
> replicated entries will have been checked on the master.

What if two simulaneous, valid changes to the same entry on two masters
produce a schema error when combined?  I haven't been tracking MMR -
does the entry end up with a schema error, or does MMR consider two
changes to the same entry a conflict and fail to replicate, or...?

-- 
Hallvard



Followup 6

Download message
Date: Sat, 08 Nov 2008 19:58:07 +0100
From: Pierangelo Masarati <ando@sys-net.it>
To: h.b.furuseth@usit.uio.no
CC: openldap-its@openldap.org
Subject: Re: (ITS#5798) MMR/mirror mode circumvents schema check
h.b.furuseth@usit.uio.no wrote:
> hyc@symas.com writes:
>> IMO defaulting schemacheck off for replication is fine because
>> replicated entries will have been checked on the master.
> 
> What if two simulaneous, valid changes to the same entry on two masters
> produce a schema error when combined?  I haven't been tracking MMR -
> does the entry end up with a schema error, or does MMR consider two
> changes to the same entry a conflict and fail to replicate, or...?

AFAIK, the last entryCSN should win.  Something like:

          MM1             MM2

time 0   csn0            csn0           (same)

time 1   csn0+1    ->    -

time 2   -         <-    csn0+2

time 3   csn0+1,csn0+2   csn0+2,csn0+1  (one wins, I assume the latest)

At all times, each entry is sane.  The one that wins is sane, the one 
that loses will be replaced by the one that wins.

The reason for this ITS and other stuff that will come shortly is that 
I've been asked to audit MMR, by designing a suite of tests that check 
functionality and reliability of MMR under possibly reproducible 
conflict, concurrency and other critical conditions.

I'm highlighting a series of issues.  I won't post ITSes or other 
notices until I find out whether it's slapd's or my tests' fault.

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
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org