Re: Invalid Add operations allowed (ITS#2243)

[ntb@mts.ru]

oops... forgot to CC message...

-------- Original Message --------
Subject: Re: Invalid Add operations allowed (ITS#2243)
Date: Thu, 30 Jan 2003 10:01:40 +0300
From: ntb@mts.ru
To: ando@sys-net.it
References:
<200301290656.h0T6u6AM095451@galois.openldap.org><36057.131.175.154.56.1043840823.squirrel@webmail.sys-net.it><3E37C7C8.F2525D88@mts.ru>
<36299.131.175.154.56.1043852845.squirrel@webmail.sys-net.it>

Greetings.

Pierangelo Masarati wrote:
> 
> > As I already say, Iplanet (and it's ancestor - Sun Directory Server)
> > enforces such check at add. It even adds dn-forming attribute/value to
> > entry if no values for this attribute is given.
> > And I can say from my experience with it and with OpenLDAP,
> > it's much easier to maintain base in consistent state
> > when dn-forming attrs added to entry automatically when needed.
> > Also I can say what RFC2251-6 doesn't disallow such operations
> > at server side, altough it isn't requires that, so slapd _can_
> > perform this and it still be rfc-compliant.
> >
> > I think best solution is adding a conf option, saying what to do
> > when such add operation comes:
> 
> I'm not in favour of this.  The rule must be one, consisting
> in the correct interpretation of the standard track.
> 
> >       - accept operation - it's current behavor;
> 
> If we agree this is not correct, I'd dispose of this option
> 
> >       - reject operation - btw, which error code must be returned?
> 
> In my opinion this is the best option, although I'm already hearing
> weeps and cries "It worked until yesterday, why doesn't it work any
> more?".  As for the error code, I propose constraintViolation,
> although objectClassViolation would be an alternative.
> 
> >       - add missing value (computed from entry DN)
> 
> This might be a safe default, at the cost of doing something
> the user had not intended to.
> 
> I just committed code that implements the two last options
> (the third is on by default, although I favor the second;
> to enable the first, #define BAILOUT in servers/slapd/add.c)
> 
> Comments?

Disposing current behavor is almost safe, but not in all cases.

example from original message:

---
dn: cn=mycountry,dc=mycompany,dc=com
objectclass: country
c: mycountry
---

in with last option in effect (which is current default
behavour after Your commit) this will produce:

---
dn: cn=mycountry,dc=mycompany,dc=com
objectclass: country
c: mycountry
cn: mycountry
---

which is an objectClassViolation.
So, schemacheck must be done _after_ adding attribute
computed from DN.

In this case first option - accept operation as is -
can be used by people crying "Why it is stop working"
as first aid. (or forever for some lazy admins,
who prefer not to change current mechs such as scripts
using ldap, samba settings, etc.. but want to proceed
to newer versions)

In last example from original ITS, on the contrary,
adding a computed value will fix an entry, and moreover,
it fix it transparently for mechanisms using/adding
such entries.

---
dn: l=mylocality,dc=mycompany,dc=com
objectclass: locality
---

will be:

---
dn: l=mylocality,dc=mycompany,dc=com
objectclass: locality
l: mylocality
---

which is correct.

And one more example from me personally:

---
dn: l=mylocality,dc=mycompany,dc=com
objectclass: locality
l: otherlocality
---

in this case reurning constraintViolation is best choice,
altough we can produce:

---
dn: l=mylocality,dc=mycompany,dc=com
objectclass: locality
l: otherlocality
l: mylocality
---

and accept it.

I think adding a value is best default (last example is an
exception), altough rejecting operation is more
"standard conforming".

SMTP /Perece/.