[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Freeipa-devel] [RFE] Permissions V2

On 12/06/2013 03:54 PM, Rob Crittenden wrote:
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
selecting which objects this apply to.

This was sort of necessary when the permissions were all in the base
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
add/delete permissions).

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 ?

Right now type implies the target used. I think it would just change to
be a targetfilter instead (or a piece of one anyway). What may be tricky
is combining a type and a user-profiled filter, and then decomposing
that, without a separate attribute.

The design changes --type to be a "shortcut" for setting location and filter at the same time. Those two are what's actually stored in LDAP, and on output "type" is added if those two match a known object type.

We may (in the RFE I'm about to file) want to make targetfilter & targetattrfilter multivalued, and e.g. make --type work on objectclass filters only.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]