Kurt D. Zeilenga wrote:
At 05:15 AM 1/21/2005, Pierangelo Masarati wrote:Not that I can imagine right now. I'm trying to understan if the current way access is checked is complete or not. I've modified backend_attribute() so that it tries to collect those attributes that are generated (via backend_operational(), which should rather be called backend_generated(), since other operational attributes, like entryCSN, entryUUID, modif* and creat* are actually stored in the database). ACLs don't yet get access to generated attributes, but other components do. Compare doesn't access generated attributes as well, and in some cases I guess it might be useful. In the patch I submitted along with ITS#3504 there's a function backend_access() that can collect and check access to operational attributes as well; the frontend-level compare operation in the same patch can compare generated attributes as well. Although being relegated to very specific tasks, I think these features make slapd yet more complete.
[possibly related to ITS#3491]
I note that entryDN is not allowed in compare.
Other than maybe completeness, is there any other reason why we need to support this?
As entryDN is operational, it fine for it not to be available for all uses. It's really only intended for use with the search operation.
Of course that's trivial,
because the assertion is always true if the asserted value is equal to the
requested DN, but I wonder why not, say, just perform the check in the
frontend? All in all what would be really missing is access control,
which could be performed by calling backend_attribute(). The whole
compare operation could be performed in the frontend by calling
backend_attribute(). In some sense, access to entryDN should be equal to
access to the pseudo-attribute "entry".
I some sense, maybe. But I rather "entry" grant permission to
the object (entry) as a whole.
just speculating... ;)
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497