Petr Viktorin wrote:
Hello,
I'm splitting up ACI work into several designs to make it more manageable.
This one is about
- Moving ACIs out of $SUFFIX
- Storing all ACI data in the permission entry
- Permission flag system for ensuring backwards compatibility
Summary of the backcompat story:
- Attributes, rights, etc. of new permissions may not be modified or
read on old servers (not possible since the ACIs aren't in $SUFFIX)
- Old permissions convert to new ones when they're modified on a new server
- Any server can assign (or remove) both old and new permissions to
privileges
There is a bit of shuffling in API/CLI option names, since the API
option name needs to match the LDAP attributeTypes.
The WIP design document is here:
http://www.freeipa.org/page/V3/Permissions_V2
Data in the permission entry
I think the schema needs to be described better. I'm assuming that
ipaPermTarget is the equivalent of current targetgroup option? And
targetfilter is the equivalent of current filter option?
If you are placing the ACI into the container based on type, then you
probably don't need the filter within the ACI (it is implicit).
In general I think some examples would be helpful.
Modifying and Upgrading Permissions
Under what conditions would there be an old or a new permission and no
associated ACI?
Option/Attribute mapping
Performing a search on the filter is a good idea but realize that it has
its limits. It is possible to create a legal filter that makes no (or
little) sense.
If type is only going to specify the location of the ACI then perhaps it
shouldn't be in the mutually exclusive list.
rob
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
