directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: regarding ACI
Date Mon, 07 Jul 2008 17:31:04 GMT
Hi again,

If I understood your problem correctly it may not be so easy/smooth to
achieve. I had thought about this long time ago and proposed extensions to
X.500 ACIs:
(see the 'parent' protected item.)

I'll have a look for the best possible solution.


On Mon, Jul 7, 2008 at 18:36, Eugen Paraschiv <> wrote:

> - I've been trying to customize the ACI rules for my DIT; the structure of
> my DIT is as follows:
>   - the users are entries of the type /iNetOrgPerson/
>   - each user has it's own structure: an /ou=contacts/ which again has a
> substructure: a list of entries of type /iNetOrgPerson/
> - the main idea is that each member has it's own private address book
> - of course I want each user to have access only to it's own private
> address book, and not the address books of the other users
> - for now, I defined one ACIItem: for the /thisEntry/ I defined a rule
> which gives the user access to that entry it's attributes and the attribute
> values; this works OK (when I browse the entire structure from Studio, I can
> only see the attributes for the user with which I binded)
> - now the problem: the next step of course be a rule to allow the current
> user (the one with which I bind) to not only access it's own entry, but all
> the subentries of that entry, which would be the logical behavior in the
> first place; to do this, I guess I would have to define a subtree with the
> entry of the current user as a root, so that I can then define the rule with
> allows the user access to that entire subtree. How do I go about doing that?
> If a ldif is needed, I will attach it to an email. Thank you. Eugen.
> --
> Eugen Paraschiv, Java Developer
> Grigore Alexandrescu 52
> Bucharest, 010626, Romania
> Tel: +40728-896170;
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

Ersin Er

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message