On 12/06/2013 03:49 PM, Simo Sorce wrote:
On Fri, 2013-12-06 at 15:46 +0100, Petr Viktorin wrote:
On 12/06/2013 03:28 PM, Simo Sorce wrote:
On Fri, 2013-12-06 at 14:14 +0100, Petr Viktorin wrote:
On 12/02/2013 02:48 PM, Petr Viktorin wrote:
On 12/02/2013 02:29 PM, Simo Sorce wrote:
It would be very nice if you can add the resulting LDAP objects in the
example, that will allow me to reason on the correctness of the
OK, I'll work on that.
I've added the resulting LDAP objects to the tests here:
Thank you Petr,
I was looking at them and I see we often use target=ldap://<dn> type for
selecting which objects this apply to.
This was sort of necessary when the permissions were all in the base and
we wanted to limit to specific entries in subtrees.
However I was wondering if we shouldn't transition/allow to user
targetfilter or targetattrfilter (this would be needed to have
For example, instead of:
(target = "ldap:///uid=*,cn=users,cn=accounts,$SUFFIX")
We could have:
(targetfilter = "(objectclass=ipaUser)")
It also occurs to me we could do very neat things like allowing manager
access with (targetfilter = "(managedby=<dn>)"), and similar.
In general using targetfilter and targetattrfilter is more flexible and
allow for applying different permission depending exacly on the object
type or even specific sets of objects of a common type. Something the
simple target filter cannot do.
What do you think ?
I don't think this should block the framework patches that are on list
now, though. I'll file a RFE for tuning how the default and "type"
permissions look. Would that be fine?
Do we need a new attribute, or do you think we can do this without
changing the schema ?
Ah, yes. Please reserve ipaPermTargetAttrFilter.
(ipaPermTargetFilter is already reserved)
Freeipa-devel mailing list