8:43 p.m.
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.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
10:01 p.m.
--On Tuesday, April 22, 2008 5:43 AM +0200 Emmanuel Dreyfus
<manu(a)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
11:21 p.m.
Quanah Gibson-Mount wrote:
--On Tuesday, April 22, 2008 5:43 AM +0200 Emmanuel Dreyfus
<manu(a)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.
1:11 a.m.
Quanah Gibson-Mount wrote:
--On Tuesday, April 22, 2008 5:43 AM +0200 Emmanuel Dreyfus
<manu(a)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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
4:43 a.m.
Quanah Gibson-Mount <quanah(a)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?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
4:56 p.m.
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 :-)
--
Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch)
Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
11:22 p.m.
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.
1:27 p.m.
Michael Ströder <michael(a)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.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
1:10 a.m.
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.
--
Emmanuel Dreyfus
manu(a)netbsd.org
8:26 a.m.
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.
1:17 p.m.
Michael Ströder <michael(a)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
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
2:57 p.m.
Emmanuel Dreyfus wrote:
Michael Ströder<michael(a)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
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1:03 p.m.
Howard Chu <hyc(a)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?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
5638
days inactive
5641
days old
openldap-software@openldap.org
12 comments
6 participants
participants (6)
-
Dave Horsfall -
Emmanuel Dreyfus -
Howard Chu -
manu＠netbsd.org
-
Michael Ströder -
Quanah Gibson-Mount