Re: Paged Results Control patch (ITS#2189)

[ando@sys-net.it]

> Pierangelo,
>    Regarding chapter 6, security considerations:
> Paragraph 1 seems to be satisfied, since one can have multiple searches
> (or other operations) happening concurrently with no problem.
> Paragraph 2: The size limit for the search is still respected, so I
> believe this condition is satisfied.

sure.

> Paragraph 3:  I'm not really sure how to interpret this one, but the
> server doesn't give an indication of the number of entries that will
> match before returning the first entries, so I would say that this is
> not satisfied.  Is this necessary to add?

I think what you're doing is fine: it seems conservative
(accroding to RFC 2696) to return 0 as count of entries
that still have to be processed; however, an estimate of
how many entries will be returned next is given by the
number of candidates (if we accept it  as a conservative
estimate, i.e. a worst case in terms of resources usage).

The point is that we should not reveal this information
unless we give the sysadmin the possibility to protect
it if required.  We would need to set up a sort of meta-ACL
that protects the count of entries that are available;
to reuse a big chunk of code we might introduce a new type
of limit in the limits stuff (see slapd.conf(5) "limits"
and servers/slapd/limits.c); I'm thinking of a

limits anonymous size.pr=10 size.pr=noEntriesLeft

to limit the size of the page a specific user might request
and to hide the number of entries left.

This would lead to a higher granularity of the page size
(the RFC states it cannot exceed the sizelimit imposed by
the server; since slapd enforces limits on a per user basis,
in this way we may allow a higher granularity.

Pierangelo.

PS: regarding the question about unnecessary mallocs, I think
I fixed the one I noticed; there's a FIXME in
servers/slapd/controls.c
where you initially malloc 3*sizeof(LDAPControl *); is it
really necessary?

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it