[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Controls and backends

Bertrand Croq wrote:

On Fri, Dec 03, 2004 at 01:05:49PM +0100, Pierangelo Masarati wrote:


There still seems to be a little problem with the backend independance:
when slapd receives a search requests, it calls
backend_check_restrictions that calls backend_check_controls that only
checks the controls supported by the selected backend, ignoring the
controls supported by the overlays. Did I miss something in the
supported controls declaration or do I need to edit each backend init.c
file?


No. The infrastructure for the controls should take care of that. I
haven't read the code that well after the latest changes; you should see
what happens. Since both ppolicy and syncprov do register controls, and
they work pretty well, I don't see why yours shouldn't. Can you
cross-check if you did anything different in this sense?



From what I read, these overlays seems to manage the replies on their
own! syncprov "connects" directly to the backends, bypassing some of the
tests (restrictions, maybe acls) done in slapd when all overlays return
SLAP_CB_CONTINUE (or when there is no overlay).


That's one thing overlays can do; but notre that even some of the frontend/backend code exploits direct calls to the backends; see syncrepl.c, saslauthz.c, sasl.c, and many more. You will see, for instance in syncrepl.c or in saslauthz.c, that a great care is used in crafting the members of the "Operation" structure any time a direct call to a backend function is performed, like using the appropriate allocators for each member and so; much like it is done by the frontend when the first direct call of the chain occurs.

The sequence is (in [] the optional portions):

a) the frontend receives a request and does basic parsing and sanity checks;
[HEAD only a.1) global overlays may muck with request data;]
b) the frontend selects the database based on the contents of the request;
c) the backend op function is invoked
[ c.1) here stacked overlays can intercept the operation;]
d) the backend function responds thru a callback; the one set by the frontend applies standard checks and does standard stuff;
[overlays can push more response callbacks in front of the frontend one, and even cause the pop chain to be interrupted at some point, so the frontend response callback is never used. In general, in this case the overlay must return a response of its own to the client.]

Overlays, like some frontend code, use direct calls to the databases for internal ops; these calls are performed by calling the original database hook for the operation, with custom response callbacks that are used on the one hand to do the desired task, and, on the other hand, to avoid the operation to return an unwanted response to the client. Any time an overlay directly responds to the client, it is desirable it occurs thru the standard frontend interface (e.g., to send an entry, thru slap_send_search_entry(), or thru any of the slap_send-*() helpers) so that access control takes place and everything else, e.g. statistics, are updated accordingly.

When exploiting internal operations, the programmer must take care of ensuring the consistency of what's done. For instance, if an internal operation is done on behalf of the original identity, its "Operation" structure must inherit the identity stuff from the original operation (i.e. the o_dn/o_ndn), so that access control can be performed accordingly. If the internal operation, on the contrary, is administrative, it is desirable that it occurs with a privileged identity, which may depend on the purpose. For instance, for access control, I'd perform internal searches required to gather access information with a privileged identity (e.g. if access info is stored in the database, like ACIs, the rootdn is used to get it, as much as the builtin ACL stuff is always accessible to determine the access rights of an identity). On the other hand, syncrepl operations are performed with a replication identity, i.e. an administrative identity but subject to regular access control, so it is privileged as much as ACLs give it the required privileges).

In this sense, overlays do not differ from builtin code, they allow a lot of freedom and they can break security (as much as builtin code can do) if they are coded erroneously. They are favored with respect to directly changing either the frontend or the backend because they are less intrusive (you can add special features and the related overhead only if required) and the same features can be exploited by different becakends (or even by the frontend, see the global overlays in HEAD).

p.




   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497