On 11/11/2013 03:56 PM, Rob Crittenden wrote:
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?
ipaPermTarget is the raw ACI target, i.e. the DN.
targetgroup is just the name
If the targetgroup option is specified, it effectively just finds the
group and sets the ipaPermTarget option to its DN.
And if ipaPermTarget contains a group DN, targetgroup will be populated
with the cn on output (in addition to ipaPermTarget with the full DN).
The next update will have examples.
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).
Sorry; that should have been target, not fiter.
The target is a bit more explicit; it has e.g. "uid=*" in addition to
the user container DN, so I'd like to keep both.
In general I think some examples would be helpful.
I'll add some.
Modifying and Upgrading Permissions
Under what conditions would there be an old or a new permission and no
associated ACI?
If a command failed unexpectedly, and also failed to clean up.
For example if the DS shuts down at the right time in the middle of a
permission-mod.
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.
Of course. This is just a syntax check.
If type is only going to specify the location of the ACI then perhaps it
shouldn't be in the mutually exclusive list.
Yes.
Martin just pointed out ticket 2355_ (Allow filter and subtree to be
added in same permission) to me today. I'll redo the mutual exclusivity
so more things are possible together.
_2355 :https://fedorahosted.org/freeipa/ticket/2355
--
Petr³
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
