Re: Subtree ACIs

[Ralf Haferkamp <rhafer@suse.de>]

On Mon, Jul 14, 2003 at 04:50:22PM +0200, Kurt D. Zeilenga wrote:
> At 04:29 PM 7/14/2003, Ralf Haferkamp wrote:
[..]
> >Thanks for the pointer. I've take a look at the drafts. If I understood
> >it correctly it makes use of Subentries when defining ACIs that scope more
> >than one entry, is this correct? If yes, is there any subentry support in
> >the current HEAD code? 
> 
> The X.500 model supports both "entry" and "perspective" ACIs, the
> former held in entries the later in subentries.  This separation
> is key to supporting access control delegation.

But "perspective" ACIs are the only ones which can apply to multiple
Entries (the ones that are in the scope of the subentry), right? (Just
asking for comfirmance if I understood this part correctly). There is
nothing like a "subtree"-ACI which is stored in the entry itself, is there?
(Wouldn't make a lot of sense in my opinion) 

[..]
> >Is it intended to remove the current implementation in favour of a solution
> >that implements the ACMs specs in the future?
> 
> The current implementation is experimental.  To that extent,
> it has fulfilled its purpose (to experiment with in-directory
> ACIs).
> 
> As far as the future goes, I personally favor* implementing the
> X.500 ACM as its complexity is well understood and proven.  I
> rather avoid re-inventing the unavoidable complexity of a robust
> access control model.  My approach was to first implement
> collective attributes (w/ subentries) [as it is a simple X.500
> administrative model] and then implement X.500 basic access controls.
Can you sumarize how much (if any) of this is already implemented in the
current code? Seems that the schema definitions for collective attributes
are already there. There are as well already a few #ifdefs  related to
subentries in back_bdb, but not much more. Is this correct, or did I
overlook something.

> As I am swamped with other things, I'm quite open to alternative
> approaches offered by those with more time/energy to work in
> the access control area.
> 
> One other approach which was discussed at ODD/SFO was
> solving this problem via a "configuration" backend which
> virtualized our current slapd.conf(5) access controls.  That
> seems like a fairly pragmatic approach.
This sounds appealing as well.

-- 
Ralf Haferkamp

SuSE Linux AG                                    - The Linux Experts -
Deutschherrnstrasse 15-19                         http://www.suse.com
D-90429 Nuernberg, Germany                        Tel: +49-911-74053-0