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

[Pierangelo Masarati <ando@sys-net.it>]

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.

The patch is coming with a brand new ITS.

p.


   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497