[Date Prev][Date Next]
Re: entryDN not allowed in compare
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
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... ;)
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497