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.
I am looking for a way to keep this mess from hapening again.
--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.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Tuesday, April 22, 2008 5:43 AM +0200 Emmanuel Dreyfus manu@netbsd.org wrote:
I had a bad experience with users uploading huge pictures, causing LDAP queries in some applications to timeout before getting a result,
Don't let them do that.
Well, there's already the standard attribute 'jpegPhoto' in 'inetOrgPerson'. So one might want to have a picture in there of just a few kB.
Have them store a URL to a jpeg stored elsewhere.
The caveat is that an application has to use another protocol to grab this BLOB. And access control has to be made consistent by other means when using different data sources => more integration effort.
I always considered the lack of server-side limits on the number/length of attribute values and the LDAP PDU size a serious threat.
Ciao, Michael.
Emmanuel Dreyfus wrote:
I don't find this in the documentation: is it possible to enforce a byte limit on an attribute or an object?
Nope.
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.
It would be even more nice to define such constraints in the subschema. This would rather be a topic for ldapext mailing list though.
Ciao, Michael.
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.
Quanah Gibson-Mount quanah@zimbra.com wrote:
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.
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?
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.
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 :-)
On Tue, Apr 22, 2008 at 08:22:56AM +0200, Michael Ströder wrote:
Emmanuel Dreyfus 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.
size can already be obtained this way:
# Reject jpegPhoto bigger than 128k overlay constraint constraint_attribute jpegPhoto ^.{0,131072}$
While it will provide the functionnality, how bad is it on the performance front? Is it usable on a production system?
And while it is still uneffective against an attacker that injects data in a multivalued attribute. But I doubt a user could do that by mistake, at least.
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.
Michael Ströder michael@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.
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.)
Howard Chu hyc@symas.com wrote:
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.
I assume you mean Add/Replace subops? In order to handle the Add subopt for Modify, I need the number of a given attribute for the object beeing changed. Do I have to perform an internal LDAP search operation to do it, or is there a simplier way?
openldap-software@openldap.org