Quanah Gibson-Mount wrote:

--On Tuesday, April 22, 2008 5:43 AM +0200 Emmanuel Dreyfus manu@netbsd.org wrote:

...

Hello

I don't find this in the documentation: is it possible to enforce a byte limit on an attribute or an object?

jpegPhoto seems to be able to absorb huge amount of data. I had a bad experience with users uploading huge pictures, causing LDAP queries in some applications to timeout before getting a result, and later causing a simultaneous crash of all LDAP replicas because of resource shortage.

Don't let them do that. Have them store a URL to a jpeg stored elsewhere. Or write an intervening app that enforces the sizelimit. But in general storing binary data like that in LDAP will cause problems.

That's a bit overstated. But certainly you can set the sockbuf_max_incoming limits to smaller values.

On Tue, 22 Apr 2008, Emmanuel Dreyfus wrote:

Right, I with I knew that before setting the thing up. Why does LDAP supports the jpegPhoto attribute, by the way, if it leads to chaos?

Probably because it seemed like a good idea at the time :-)

Michael Ströder michael@stroeder.com wrote:

Would be a nice feature for slapo-constraint.

I could work on that if I find the time. If someone else starts implementing it, I'd appreciate a mall so that we don'(t duplicate efforts.

Michael Ströder wrote:

It would be even more nice to define such constraints in the subschema. This would rather be a topic for ldapext mailing list though.

Readers interested in this topic are invited to comment my proposal on ldapext mailing list:

http://www.ietf.org/mail-archive/web/ldapext/current/msg01367.html

Ciao, Michael.

Emmanuel Dreyfus wrote:

Michael Strödermichael@stroeder.com wrote:

...

Would be a nice feature for slapo-constraint. Maybe an additional <size> parameter limiting the number of bytes for BLOB attributes or number of character in case of character-based string syntaxes. And maybe a limit for the<number> of attribute values for multi-valued attributes.

I just had a look. the size constraint is trivial to implement. number is a bit more difficult.

If I understand correctly, constraint_violation() should perform an internal LDAP search for the constrained attribute, count the existing, and somehow keep a count of how many time constraint_violation() is called for a given attribute and a given operation.

I am not sure slapo-constraint is the right place.

I think it would be fine there for now. The 2.4 Attribute structure already maintains a counter for the number of values present. For an Add operation it's a no-brainer to enforce this constraint. For a Modify operation you will have to keep track of Add/Delete subops, but that's not too difficult.

Might be something to think about for OpenLDAP 3.0 - number constraints defined in the subschema, and different subschemas controlling different subtrees. Could simply extend the current config tree with a new "ScopedSchema" objectclass, containing schema elements that only pertain to specific branches, overlaid on top of the existing global schema. (It doesn't make sense to me to have to completely duplicate all the basic core schema everywhere you want to set up local customizations...)

Obviously the current schema allows advisory attribute size limits, which have historically been completely ignored by LDAP servers. It would be quite a change to introduce hard size limits here, and you'd also have to get agreement from the X.500 side too. (I'll note that back-ndb uses the attribute size limits in existing LDAP schema, and enforces them as hard limits.)