[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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

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.


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.


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