[Date Prev][Date Next]
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.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"?).
We already have separation of entry add/delete from attribute
add/delete from value add/delete.
I don't think we needIn 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).
another way to distinguish entry v. attribute v. value
I see no reason to split "manage" (manage the DSA IT), atMy 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.
least not yet.
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
Now, one area not discussed here is the separation of real andHere, 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.
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).
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