Re: More granular privileges in ACLs (Was: (ITS#3625) [enhancement] per-operation ACLs)

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:

> Howard Chu wrote:
>
> > Kurt D. Zeilenga wrote:
> >
> > > At 08:56 AM 4/2/2005, Pierangelo Masarati wrote:
> > >  
> > >
> > > > Here, my comment is that currently we don't save the "realdn" after 
> > > > an authorization: conn->c_dn is set to the authzDN; but, I admit, I 
> > > > need to refresh my insight into that portion of code.
> > > >   
> > >
> > >
> > > We currently don't save the real dn.
> > >  
> > >
> > > > If this is not true, or if keeping it around does not imply too 
> > > > much reworking, I think adding the "real" specifier to the above 
> > > > cases (and wherever applicable) should be (almost) trivial.  I'll 
> > > > have a look at it.
> > > >   
> > >
> > >
> > > Though about a ,real... but as the admin might want to do
> > > something like:  if real DN is X and effective DN is Y, grant Z,
> > > hence we may need "by real=X effective=Y" capability.
> > Yes... Although since our current "by dn=X" clause is already the 
> > effective DN I would leave that unchanged, and just add "realdn" thus
> >    access to X by dn=Y realdn=Z
> >
> > with the realDN ignored if not specified (and so equivalent to 
> > current behavior).
>
>
> I have a prototype implementation (needs comprehensive testing, but 
> passes basics) that's exactly as you say above.  I've added another 
> pattern that's totally equivalent to the current 
> "dn[.style[,modifier]][=pattern]" excpt it's prefixed with "real"; it 
> also implements "realusers" (useless, except if a user proxyAuthzes 
> asserting an empty identity) and a (absolutely useless) 
> "realanonymous"; the "realself" and "realdnattr" patterns may be more 
> interesting; the "realself<access>" as opposed to the "self<access>" 
> completes the framework.  I have no opposition to using 
> authcDN/authzDN as well.
>
> For the realdn, I'm currently assuming that the only place where 
> identity may change is inside parseProxyAuthz(); I added a o_realndn 
> field to the operation structure; this field is supposed to be 
> BER_BVNULL unless proxyAuthz occurred; if it is NULL, the "realdn" 
> clause, if present, is evaluated using the o_ndn field; if it is not 
> null, it behaves as expected.  Maybe, in case of SASL bind, we could 
> store in o_ndn the constructed DN before authz via authz-regexp rules.

Does this really belong in op->o_realndn? Perhaps we should have it back 
in conn->c_dn.

As for storing the DN prior to authz-regexp, I'm inclined to disagree. 
The result of regexp mapping is still an authcDN, not an authzDN, and 
I'm not convinced that we need to refer back to the SASLDN after mapping 
has been done.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support