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

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

Kurt D. Zeilenga wrote:

> I see that you talk of both value and entry permissions.
> We already have separation of entry add/delete from attribute
> add/delete from value add/delete.
>  
Yes.  What we may need is, among these already well-separated areas, 
extra granularity (e.g. add vs. delete; what about "a" and "z", for "zap"?).

> I don't think we need
> another way to distinguish entry v. attribute v. value
> permissions.
>  
In fact, "add" and "delete" assume different meanings when applied to an 
attribute or to "entry" (or to "children").  We don't need to mimic too 
much other specifications, provided ours is clear enough (I think it is, 
right now, even if it appears to be yet a bit hard for some users/admins).

> I see no reason to split "manage" (manage the DSA IT), at
> least not yet.
>  
My point (not clear enough, I guess) was to incorporate in the "manage" 
level all operations that usually require a very high level of privilege 
(or are not allowed); my interpretation of "import" and "export" is 
something close to "rename" across databases/DSAs, so I'd incorporate in 
"manage" the primary purpose of manageDSAit, plus renaming across 
databases/DSAs, subtree deletion (whenever we're able to specify it), 
non-leaf renaming and so on.  At this point, fine grain privileges may 
be desirable to split out what type of operations within the "manage" 
level one can do.

> Also, "auth" means permission to use information in authentication
> and authorization processes.  It is neither a permission to
> authenticate nor permission to assume an identity.  Of course,
> not having permission to use a piece of information in authentication
> and authorization process can lead to permission not being granted
> for these or other actions.  I don't see any particular need to
> split it.
>  
OK.

> Now, one area not discussed here is the separation of real and
> effective permissions.  That is, at present, we do everything
> based on the user's effective authorization identity.  It would
> be nice to base decisions on the user's real authorization
> identity as well.  Howard and I bounced around some ideas in this
> area (namely adding realdn, realself, realgroup by parameters,
> or the like).
>  
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.

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.

p.


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