[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: More granular privileges in ACLs (Was: (ITS#3625) [enhancement] per-operation ACLs)
At 09:24 AM 4/2/2005, Kurt D. Zeilenga wrote:
>At 08:56 AM 4/2/2005, Pierangelo Masarati wrote:
>>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 think a strong argument can be made that add v delete separation
>would be good to add. I note that we already have some ways
>of controlling add versus delete at the entry level, and even
>incomplete ways at the the attribute level. (e.g., filters).
>
>>>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.
>
>All the plus things you name should require manage DSA IT permissions.
s/should/should not/
I understand that your point is that you want to expand "manage"
to include items that "require a very level of privilege",
but I don't see why "import"/"export" or "rename" accross
databases/DSAs would require such a very level of priviledge.
These are actions are not all that exceptional DIT modifications.
That is, the DIT model doesn't disallow them. What I mean
"manage" to do things that require a DIT model override.
>These operations are upon the DIT, not the DSA IT. Manage DSA IT
>permission should be needed to override a DIT restriction, for
>instance to change values of a NO-USER-MODIFICATION attribute.
>
>>>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.
>
>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.
>
>Kurt