On 11/11/2013 04:48 PM, Petr Viktorin wrote:
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
I've updated the design with
- updated schema (this time the OIDs are even reserved properly!)
- longer attribute descriptions with examples
- updated update algorithm based on discussion with Simo
Additionally, I've updated draft designs this one references [0, 1]. The
CLI/API parts of those aren't finished but the LDAP should be ready for
criticism.
For examples, I felt that anything I show as an example should also go
in the test suite, so I added the tests. (If you're into wiki design I'd
appreciate ideas about how to make that section better.)
If you need any more examples, or see some dangerous corner cases, tell
me and I'll add them.
There is still a race condition when the subtree changes, e.g. when
you'd move an ACI from $SUFFIX to cn=users,cn=accounts,$SUFFIX, the
rights are revoked between the times the ACI is removed and re-added.
At this point I'd rather document it and file a bug (and possibly start
working on it right after this) than redo the internals in yet another
way in the same update.
[0] http://www.freeipa.org/page/V3/Anonymous_and_All_permissions
[1] http://www.freeipa.org/page/V3/Managed_Read_permissions
PS. the hack I used to generate the test plan for mediawiki is here:
https://github.com/encukou/ipa-tools/blob/master/mw-format-tests.py
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
