Re: [ldapext] Nested group (was: groupOfEntries object class proposal)

[simo <idra@samba.org>]

On Wed, 2007-09-19 at 22:03 +0100, Andrew Findlay wrote:
> On Wed, Sep 19, 2007 at 03:32:34PM -0400, simo wrote:
> 
> > Sorry but I see a fault here as well.
> > Once you add, as a member, a user controlled by a foreign entity your
> > security is already screwed if you don't trust that entity.
> > If you trust it then you trust they will not try to use their power to
> > exploit your system.
> 
> True, but the separation of attributes can limit how much of my
> resource a malicious admin can give away.

How? The malicious admin has already full access to the resources he can
have access to, he does not need more. The "malicious" one, will never
add other entries, as you would spot them monitoring the system, he will
just use the one "you" gave access to, to not make you suspect.

> Howard's suggestion of a limit on the 'expand groups' control leads to
> another idea: split the nestedGroup attribute into two again:
> 
> 	nestedGroupOfEntries
> 		The group entry that we point to can only contain
> 		leaf-nodes
> 
> 	nestedRecursiveGroup
> 		The group entry that we point to may contain further
> 		nested groups as well as leaf-nodes.

Why not also:

nestedRecursiveGroupTwoLevels
nestedRecursiveGroupOnlyThirdLevelButNotFirstOrSecond
SCNR :-)

Seriously, this may seem a good idea on the paper, but what people will
use in the end is always nestedRecursiveGroup as soon as they get burned
with the limitation of nestedGroupOfEntries.
So you will effectively gain nothing, except adding complexity.

I don't think we should be in the business of deciding policies, just
providing generic mechanisms that architects can use. They will add the
policies they think they need on top.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer
email: idra@samba.org
http://samba.org


_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext