Lucas Yamanishi wrote:
On 05/17/2012 09:34 AM, Rob Crittenden wrote:
...
The ACIs need a little bit of work. The name of the aci needs to
match the name of the ACI that permission is being granted to, with a
prefix of permission:. So it should look more like:
aci: (targetattr = "attribute1 || attribute2 || attribute3")
(version 3.0; acl "permission:Read custom attributes"; deny (all)
(userdn = "ldap:///anyone"; and userdn != "ldap:///self"; and groupdn
!= "ldap:///cn=Read custom
attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
For the second ACI you don't need add and delete, those are
entry-level permissions. You might want to add compare though.
We also tend to separate things you can do to your own entry from
things you can do to others. So we would break this out into some
selfservice ACIs and permission ACIs. Not saying what you're doing
won't work.
rob
BTW, what's the origin of the naming restrictions? Is it an IPA thing?
Yes, we are trying to hide the complexity of ACIs behind the permission
concept. We take advantage of nested group membership and use that to
delegate access. We create an ACI that grants permission to do something
to a group (in this case a permission). This permission is then a member
of a privilege which is a member of a role which itself has users,
groups, etc as members. So being a member of a role grants access to all
permissions associated with it.
An ACI is just a string of text so we need some mechanism to link an ACI
with a permission object so we use this comment/name section. We added a
prefix to distinguish between selfservice permissions and normal
permissions (and perhaps future prefixes as well).
Here are my updated ACIs:
<pre>
dn: dc=sesda2,dc=com
changetype: modify
add: aci
aci: (targetattr =
"privateAttribute1 ||
privateAttribute2 ||
privateAttribute3 ||
privateAttribute4")
(version 3.0; acl "permission:Read custom attributes"; deny (all)
(userdn = "ldap:///anyone"; and
groupdn != "ldap:///cn=Read custom
attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com");)
dn: dc=sesda2,dc=com
changetype: modify
add: aci
aci: (targetattr =
"privateAttribute1 ||
privateAttribute2")
(version 3.0; acl "permission:Does this need a special name?"; allow
(read, search, compare)
userdn = "ldap:///self";;)
Use the prefix selfservice and name it something like: selfservice:
Users can read their own private attributes
dn: dc=sesda2,dc=com
changetype: modify
add: aci
aci: (targetattr =
"privateAttribute1 ||
privateAttribute2 ||
privateAttribute3 ||
privateAttribute4")
(version 3.0; acl "permission:Manage custom attributes"; allow
(read, write, search, compare)
groupdn = "ldap:///cn=Manage custom
attributes,cn=permissions,cn=pbac,dc=sesda2,dc=com";)
Otherwise looks ok. ACIs often have subtle problems so I'd test
casefully. Assuming these work ok you might try enhancing them to limit
their scope to just users by adding (target =
"ldap:///uid=*,cn=users,cn=accounts,dc=sesda2,dc=com";). This might speed
up ACI processing ever so slightly, and ever ms counts.
rob
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
